title: Structure Editors: A Literature Review author: Jared Forsyth featured: true tags: categories: - structured editors description: All the editors date: 2019-2-23 --- I've been meaning to publish this for a long time.
2067

Structured Editors: A Literature Review

code-playground
{"id":"kbi296ldkx1214btbgluhoher0m4fxic","created":1479519680113,"modified":1480223185974,"collapsed":false,"content":"loadJS('https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.2.2.min.js').then(() => {\n  Kinvey.init({\n    appKey: 'kid_SkPgJV6bg',\n    appSecret: '2e899439ee034f69ae1282bde26899d3',\n  });\n  var answersStore = Kinvey.DataStore.collection('answers', Kinvey.DataStoreType.Network);\n  if (!Kinvey.User.getActiveUser()) {\n    Kinvey.User.signup().then(user => window._user = user)\n  }\n  parent.addAnswer = (data) => answersStore.save(data)\n})\n\nclass Submit extends React.Component {\n\tconstructor() {\n  \tsuper()\n    this.state = {\n    \tsubmissions: [{link: '', isMine: false}],\n      contact: '',\n      name: '',\n      loading: false,\n      err: null,\n    }\n  }\n  \n  update(i, news) {\n  \tconst items = this.state.submissions.slice()\n    items[i] = {...items[i], ...news}\n    this.setState({submissions: items})\n  }\n  \n  remove(i) {\n  \tconst submissions = this.state.submissions.slice()\n    submissions.splice(i, 1)\n    this.setState({submissions})\n  }\n\n\tsubmit = () => {\n\t  if (this.state.loading) return\n\t  this.setState({loading: true,err: null})\n  \tparent.addAnswer({\n    \tcontact: this.state.contact,\n      name: this.state.name,\n      submissions: this.state.submissions,\n    }).then(\n    \t() => this.setState({loading: false, submissions: [{\n      \tlink: '', isMine: false,\n      }]}),\n      err => this.setState({loading: false, err: true})\n    )\n  }\n\n\trender() {\n\t\treturn 
\n \t

Know of something cool that's not on this list?

\n

hint: to search, press \"/\"

\n \t{this.state.submissions.map((sub, i) => (\n \t
\n \t this.update(i, {link: e.target.value})}\n />\n \n \n
\n ))}\n this.setState({\n \tsubmissions: this.state.submissions.concat([{link: '', isMine: false}])\n })}\n >Add link\n
\n this.setState({contact: e.target.value})}\n />\n this.setState({name: e.target.value})}\n />\n
\n \n \t{this.state.loading ?\n \t'saving...' : 'Submit!'}\n \n {this.state.err && 'Failed to save :('}\n
\n }\n}\n\n\n\n// @playground-split\n\nlabel {\n flex: 1;\n //padding-left: 10px;\n}\n\ninput[type=checkbox] {\n margin: 0 10px;\n}\n\nbutton {\n align-self: center;\n margin-top: 10px;\n}\n\n.link {\n display: flex;\n align-items: center;\n margin-top: 10px;\n}\n\ninput {\n padding: 5px 10px;\n}\n\n.contacts {\n display: flex;\n}\n.contact {\n margin-top: 10px;\n flex: 1;\n}\n\n\nh3 {\n align-self: center;\n font-size: 14px;\n margin: 0;\n padding: 0;\n margin-bottom: 10px;\n}\n\nh1 {\n align-self: center;\n font-size: 20px;\n margin: 0;\n padding: 0;\n}\n\n.form {\n font-family: sans-serif;\n //align-items: center;\n width: 450px;\n display: flex;\n flex-direction: column;\n}","type":"code-playground","editor_collapsed":true}
835

# Stuff coming together

666

Org

8

Common arguments against

You could get most of the benefits in an unstructured editor using clever incremental parsing/type checking techniques that are well understood by now. http://lambda-the-ultimate.org/node/3567

I'm going to stand by my critique. The ergonomics of structured editing is a show stopper for anyone but novices. Anything that puts you into a rigid mode where you have to fix something before continuing is bad in most cases; e.g., consider evil modal dialog boxes. Imagine a word processor that forced you to fix spelling mistakes before typing the next word!

31

Advantages of SDE that I don't really buy

28

Advantages of Text

21

Coming up with a standard on-disk representation

So there are a number of formats that do what you are describing, with all sorts of differing semantics. Some questions that arise, and which your simple-and-general format will need to address: * Can nodes be labeled, in addition to their identity? * Are there different types of nodes? * If so, can nodes have more than one type? * Can edges be labeled? * Do edges have identity? * Are there different types of edges? * Are edges directed? * Can an edge's head be the same as its tail? * Must edges only link nodes, or can they link edges? * Can an edge start/end at itself? * Must the graph be connected? * Can there be redundant edges? * If things have types, are types represented in the graph, or external to it? * What are the semantics of the labels? Are they text, typed data, etc.? * Can nodes be used to label things? * Can edges be used to label things? * Can subgraphs be used to label things? * Can subgraphs be used as nodes? * Can nodes have content? * Can nodes contain subgraphs? * If nodes can contain other parts of the graph, are there nesting rules? If so, how are they enforced? * What sort of operations are supported on the graphs? * Assuming that there are operations to visit all nodes/edges, are they stable (e.g. does adding/removing a node cause the order in which other nodes are visited to change)? * Does the storage format cache information about the graph to optimize common operations (and is this information saved?) * Are concurrent operations supported? * Can graphs be merged, unified, extracted, etc.?

13

Invalid syntax?

42

Problems w/ past structure editors

in my opinion you definitely do not want to limit the user to constructs which already exist. This forces an implementation order - you always have to declare/build up your toolkit first, and then build on that. Using earth as a metaphor (where support is dependency), you can never build any overhangs, to be filled under later.

15

Awkward input methods

2

because their transformations took a long time to implement, bogged them down.

I'm planning on having a vim normal mode, where I feel like you can do most stuff just naturally? Maybe that's naiive. Or maybe it will fall out of having a declarative grammar for the language

58

Actions

18

It's not about typing less or syntax

7

Structure argument - representation / modeling the domain

51

Fluid typing

34

Alternative Views to "text looking"

117

Visual look / feel

55

Viewing

9

Module systems

32

Graph representation

24

Version control / Semantic Diff

39

On-Disk Storage

NOTE there are bunch of papers that I still have to read (deleted b/c there will be lots of editing)

Readable code!! by Laura https://www.youtube.com/watch?v=B3X_nhJ61Ak

9

THinks I'm looking forward to

having it be normal / easy to make an editor plugin that changes the rendering of some common pattern / library / etc.

rendering JSX as the layout will be (+aphrodite aware would be so awesome)

rendering react-storybook or react-sandbox stuff on the side

rendering observables operators w/ marble diagrams

also render `TODO` comments better, and allow attaching metadata to the TODO comment do it's structured as well. This would mean that the serialized representation would lose some of that, so it'd be better to have a rich serialization in that context

3

:i: woah so about poorly-encoded state machines & state errors -> a lot of things where there's something to be initialized, and then we can use some methods or whatever.

But what if we need is to break off all the stuff that's depending on that initialization and put it into a separate class, and have that be a child of the main thing or something. Is that generally what we want?

I know in java classes are **crazy** frictioned, and annoying to set up lots of them. so maybe that's a problem.

2

Table

table
{"id":"r9w9czq0kjj5benwwsif01p863koje1e","created":1480230187693,"modified":1480230187693,"collapsed":true,"content":"","type":"table","tags":[],"table":{"matrix":[["Name","Year last active","Demo","Has \"Gui\" elements","Refactoring","Typed","SDE full/mix/no","Lang","Plugin","Usable"],["Sediment","2015","sediment.io","y : types shown above the function, rich docs displayed on the side","-","y","full","invented","n","C"],["Prune","2015","","n","+","n","full","javascript","n",""],["??","2015","","n","~","n","full","lua","n",""],["East","2009","https://sites.google.com/site/rathereasy/eastwest","n","n","y","full","invented","n","F"],["Makepad","live","makepad.github.io","n : but the zoom to collapse is cool","n","n","full","javascript","n","A"],["Golem","2015","shem.io","y : notebook","~ (can splice in the body of a fn)","y","full","invented","n","A"],["Cirru","live","cirru.org","n","n","n","full?","clojurescript","n","C"],["","","","","","","","","",""],["","","","","","","","","",""]]}}
11

11

Notablemind stuff

3

symlinks

tags should mirror

source should mirror

7

Sources

umm idk

go through the whole db & assign numbers to each source (rebuild dynamically) in depth-first, preorder traversal

2

so maybe have a source be a node type (not a "belowbody"),

hmmmm although I can just as well get the belowbody stuff going.

and then symlinking would render great

but then the belowbody thing would just be a reference to the thing, with an optional page number / hour:minute / whatever

19

My Thoughts & Writings

Things I'm going to look at:

`gofmt`, `reasonfmt`, myntax --> maybe starting from a perspective where "we're standardizing the serialization format to remove as much arbitrary formatting as possible, so that pretty printing becomse really easy"

6

Structured editing vs plain text from a UI perspective

I think modal structured editing is the grail

arguments for†

3

arguments against

can't do arbitrary edits

what about preserving all the nonstandard formatting? ans: don't do it

4

What can visual elements get you? (and visual elements will be easier to do in a structured environment)

moonshine

maybe also the bret victor stuff?

... other notebooky stuff

5

A different way of displaying things (not just methods in a column, ordered somewhat arbitrarily)

eve

leo?

Conception

my ideas

What about moving away from ASCII on disk?

7

Keywords

structured editor

syntax-directed editor

projectional editor

semantic editor

2

maybe semantic-oriented programming?

https://en.wikipedia.org/wiki/Semantic-oriented_programming

195

Actual papers

3

Paywalled :(

Structured Editor Support for Modularity and Data Abstraction http://dl.acm.org/citation.cfm?id=17919.806835

http://ieeexplore.ieee.org/iel5/2225/361/00006888.pdf

170

Read

24

A Structure Editor for the Program Composing Assistant http://www.doiserbia.nb.rs/img/doi/1820-0214/2006/1820-02140601065S.pdf

2006

4

Problems w/ past structure editors

3

in the ealiest days of structure editors, you had to enter the structure as a top-down tree traversal (e.g. indicate that you are writing a binop, then the op ("*"), then the first el, then the second el)

usual fix for this is to do a hybrid approach, where unstructured text is added and then parsed

and you switch between the two edit modes

4

references to other thigns

Mentor and Centaur [5] generate a structure editor from a format definition

Synthesizer Generator [28] cornell

5, 18, 28, 14, 23, 22

14

ProCompass (their thing)

9

Actions

ordered_list
{"id":"umt8asi61nmxrliys22kiyoe7cxhn2u3","created":1479445124199,"modified":1479445124199,"collapsed":true,"content":"move though structure","type":"ordered_list"}
ordered_list
{"id":"f5udhjbmyzx3pd6wviinjz50alkbgasb","created":1479445132767,"modified":1479445132767,"collapsed":true,"content":"add item before/after","type":"ordered_list"}
ordered_list
{"id":"wgf7fzzzqw3qlpy6n5tuovx5xb4srr7e","created":1479445138446,"modified":1479445138446,"collapsed":true,"content":"modify current node","type":"ordered_list"}
ordered_list
{"id":"fbke2qqvybf7akoawtvh9kq32ikke075","created":1479445143247,"modified":1479445143247,"collapsed":true,"content":"remove current node","type":"ordered_list"}
4 ordered_list
{"id":"6vupoxo45n2t77ybxzx1w9x1zyq5ert7","created":1479445146246,"modified":1479445146246,"collapsed":false,"content":"refactor current node","type":"ordered_list"}

change if to while

encapsulate a set of statements into a fucntion body

split function into blocks

3

copy / paste

context - dependent > the clipboard contents are truncated to the largest appropriate subtree that could be inserted at the current point

:!: also allow selecting a subset of the statements in a block to paste, for example

a "template", such as `int a = 0`, w/ three possible holes `? ? = ?`, and you replace the `?` with something

9

Citrus: A Language and Toolkit for Simplifying the Creation of Structured Editors for Code and Data http://repository.cmu.edu/cgi/viewcontent.cgi?article=1177&context=hcii

2005

huh, this is a toolkit for creating structured editors

VERY gui, like Visual Basic style. not really my jam?

but interesting in thinking outside of the mostly-text box

:!: thinking about a graph editor being a structure editor...

3

modeless structure editing http://www.cs.ox.ac.uk/bernard.sufrin/edit.pdf

mostly talking about how to enter an expression fluidly e.g. `1 + 2 * 3` in left-to-right, without any fanciness

example code is in haskell

36

Structure Editors – Old Hat or Future Vision? https://www.fbi.h-da.de/fileadmin/personal/b.humm/Publikationen/Gomolka_Humm_-_Structure_Editors__Springer_ENASE_.pdf

Made a structure editor for lisp

had people use it, conducted surveys

people prefer the structured editor, but "objective improvements are measureable, yet not significant"

2

:?!: "What the programmer thinks is what they see in the editor"

A programmer designing a piece of code thinks in structures: classes, methods, blocks, loops, conditionals, etc. Using a textual program editor they have to codify those syntactically using parenthesis, etc. The compiler then parses the syntactic elements and re-creates the structures in the form of an AST -- the same structures which the programmer originally had in mind.

"We analyze the requirements of a usable structure editor"

20

Principles

2 ordered_list
{"id":"xns1ct4smbs26hxqci1mchu8g8ew8y5r","created":1479446770839,"modified":1479446770839,"collapsed":false,"content":"Focus on the net code (?)","type":"ordered_list"}

don't display the code in a way that's hard to read / understand

4 ordered_list
{"id":"61ypzjwlkppuccdzrw9mhiynm08bvyud","created":1479446776367,"modified":1479446776367,"collapsed":false,"content":"Do not restrain the programmer","type":"ordered_list"}

some [1,2] prevent the creation of syntax errors

2

"This had the effect that simple operations which change the structure of the program became quite complex, e.g. removing a parenthesis and inserting it somewhere else"

:!: will have to address this in my stuff

4 ordered_list
{"id":"ipzzy7cnt0aqo7pm48pzek7oh093folm","created":1479446801050,"modified":1479446804386,"collapsed":false,"content":"Keep the layout compact","type":"ordered_list"}

make reading & understanding the code smooth

2

"should be as compact as the plain text representation"

:t: dunno if I'm totally on board, now that screens are pretty big

2 ordered_list
{"id":"onclvgk2ql9i8i0fs1fbfivmrdzsm3n4","created":1479446892158,"modified":1479446892158,"collapsed":false,"content":"Keep common look and feel","type":"ordered_list"}

as similar as possible to widely-used editors

2 ordered_list
{"id":"qje7pjno0z4q38rstsljpz823i93lof0","created":1479446946709,"modified":1479446946709,"collapsed":false,"content":"Do not introduce new dependencies","type":"ordered_list"}

"should not necessitate changes to the programming language or the way programs are stored"

2 ordered_list
{"id":"5walen8i0706k6h25cji6hfmiymtwbzs","created":1479446952061,"modified":1479446952061,"collapsed":false,"content":"Make the layout configurable","type":"ordered_list"}

colors, etc.

3 ordered_list
{"id":"2wjlnnqv61e28xhupa4cofeo2du59jug","created":1479446957700,"modified":1479446957700,"collapsed":false,"content":"Leave the choice to the programmer","type":"ordered_list"}
2

"some programming tasts might be easier to achieve w/ a simple SE, an advanced SE, or a textual editor. Should be able to swap between editors & editor modes"

I also want to disagree with this - I think text should be ditched completely

5

Related work

Subtext!

3

re "A Structure Editor for C#" [18]

programmer is required to change the way they type (`{` etc aren't typed at all, and aren't displayed)

:?!: Our philosophy is that the programmer may type exactly the same code with the textual and structural editor in order to minimize the learning curve and to easily switch between editors

LOPs, projecting editors...

structured editors: old hat or future vision https://books.google.com/books?id=yj66BQAAQBAJ&pg=PA93&lpg=PA93&dq=new+programming+language+structured+editor&source=bl&ots=aTc_2-GEaI&sig=CD_gIGKBRAYVSJHSUqgRveFguzE&hl=en&sa=X&ved=0ahUKEwjdndrEka_QAhXHylQKHQFsCOw4ChDoAQgnMAI#v=onepage&q=new%20programming%20language%20structured%20editor&f=false

97

kirill's PhD thesis http://www.guilabs.net/

can go pretty minimal

can go pretty minimal

93

His "Diplom" 132 pages http://www.osenkov.com/diplom/contents/1/4/

http://www.osenkov.com/diplom/KirillOsenkovDiplom.pdf

74

Introduction

46

Principles of structured editors

3

Atomicity

preserve the AST

atom changes that preserve language invariants

2

Correctness

preserve syntactic / AST structure correctness

8

Usability

"can reduce the number of primitive user input operations (mouse clicks, key strokes)"

don't have to worry about braces, code is formatted automatically

"an intelligent scrollbar" - sounds like Sublimes 1000 foot view... not super tied to SEs

2

"breadcrumb" showing the lineage of parent AST constructs

hmm might be interesting? IntelliJ does this for the package path

"key stroke prediction based on statistics"

Wesner Moise gives a probable answer to this in [WesnerM1]: … Such graphical editors won't actually appear much different from text editors; they may even look the same as text editors, with some differences.” Thus structured editors could mimic traditional text editors to provide familiarity but still retain the advantages of structured editing.

7

Presentation

easily skinnable

2

"preserving a team's guidelines becomes a snap"

in fact, I'd say they become irrelevant :P

the possibility to collapse everything (well code folding is old hat)

2

The order in which the declarations are physically stored in the file would become separated from the logical order in which they are presented to the user. Different developers could even have the same code sorted as they want it.

:!: this is a kye thing

3

Extensibility

macros!

Thus very concise and expressive shortcuts for long pieces of code could be defined, which could be expanded into longer code sections during the code generation. The difference between such macros and, say, C #define macros is that the structured macros (unlike C macros) would be language-aware, and thus all the type-checking and verification can actually take place. The problem with C macros was exactly the lack of language-awareness – the substitution took place before parsing, at the preprocessing stage. With language-aware macros the substitution takes place after parsing – language constructs are being inserted into the existing AST, thus allowing all checking visitors to run on the final tree. Moreover, the editor’s grammar and type-checking facilities could only allow inserting macro instances at correct places in the tree. This eliminates the problems of text-based macros and preprocessing.

9

Implementation

5

could really simplify the implementation of many components

code completion

refactoring

debugging

edit & continue

The thing is, it is easier to make the IDE intelligent if there is no need to constantly round-trip between text and AST. A good example is extracting a method, which would be simpler to implement in comparison with some current implementations, where a lot of effort has to be put into the round-tripping. When some code has to be inserted into the program with a text editor, a major problem is finding the correct place to insert and take care of the formatting. A structured editor takes care of the formatting.

2

eliminating the need for a background compiler

:t: but you still need a type checker? which could potentially be expensive

2

Performance

we can expect perf to be better? (but I think type inference is much more expensive than parsing...)

7

Storage and Version Control

changes could be stored & registered at the level of mutations

the code being edited could be a database repository on a possibly remote server

could allow several people to update the same code @ the same time

lots of merge conflicts disappear

all code checked in will be at least syntactically correct (and type correct too if that's integrated into your editor system)

:?!: Moreover, the check in process as such, could be replaced in the future by more fine-granular “transactions on code” – literally each change would be registered in the repository as a transaction and one could group changes manually to the desired granularity level, thus grouping changes to larger entities (for example, one day’s work). The change groups could be grouped too (design pattern Composite) to encapsulate features, milestones, products, etc.

Static analysis & Source code querying

3

Help w/ learning the language

an SE is more explicit about the language constructs being entered.

ppl don't have to learn the textual syntax in addition to the higher-level representation

27

Disadvantages & possible difficulties

6

Usability

While editing text is **straightforward and consistent** (only some basic operations are needed, such as insert a character, delete a character, move the caret, etc), editing the AST structure on the screen requires learning how to operate on each node of the program.

Moreover, editors that force the user to use menu, toolbars or the mouse during editing are most probably destined to fail. Text editors allow to edit programs using keyboard only and users won’t give up this ability.

must be able to just use keyboard

keypresses must not be much greater

consistency is important

2

Lack of familiarity

text editors are all alike, and so have low barrier of movement between them

6

Lack of flexibility

hmmm interesting claim

2

that structured editors, in order to be ideal, would want to relax some strictness constraints to temporarily allow syntactically / semantically incorrect programs?

not sure I agree

"The editor shouldn't stand in the way"

6

IDE Dependency

plain text is portable

don't lock people in to your specific tool

could have the option of storing source code to plain text files

or the storage format could be standardized (just like a programming language syntax is standardized)

:?!: Beside standardizing programming languages of the future, it will probably make sense to simultaneously standartize the structured storage/representation format for programs in that language.

2

Preserving source code formatting

I actually want to ditch custom formatting entirely :D long live the pretty printer

4

Standardizing difficulties

creating a standard sounds like it would be crazy hard

2

Coming up with standards for a structured editor for a language is a highly challenging and vastly non-trivial task. Such a standard would need not only to cover the appearance of all language constructs in all possible contexts, including margins, padding, colors, border thickness, styles of backgrounds etc. but it would also have to describe and formally specify the editing behavior, keystrokes, visual changes in display and so on. Such a specification would probably be more voluminous than the HTML 4.0 specification, because HTML only covers static presentation and does not include complex runtime behaviors exhibited by structured editors.

I think this might be assume more needs to be standardized than would actually be the case though...

6

Existing research

3

Problems w/ building structured editors

the complexity of making a parse tree interactive

a fairly complex framework of visual controls is necessary

2

Intentional Programming

book "Generative Programming", chapter 11

3

Functionality of the structured editor

:!: :!: ah, this one is hybrid. statements, method parameters are just plain text :(

I'm suddenly much less interested

3

Architecture

2

undo/redo

:t: I think I want function-level undo/redo!

Blocks

Implementation of the functionality

Implementing the C# editor

Integrating into sharpdevelop

Summary

https://blogs.msdn.microsoft.com/kirillosenkov/2009/09/09/first-videos-of-the-structured-editor-prototype/

13

In process TODO finish this

12

(in process of reading) "LORAX" Speaking for the Trees: a New (Old) Approach to Languages and Syntax http://ecee.colorado.edu/~siek/moss_msthesis.pdf

CURRENT PAGE: 18

2004

4

References

Charles Simonyi's Intentional Programming from the 1990s

Lang provides an interesting perspective [33]

The Fortress Language [2] [43]

:?!: "The limitations of parsers make languages difficult to extend and severly constrain the choice of notation

2

:?!: any class of structured documents, (recipes, essays, math problems) could be represented with a language defining the required elements and their relationships to each other

:t: think about this

ooh I like this figure

ooh I like this figure

:!: "It's no longer possible for the programming to *read* the program one way while the parser disagrees"

"Syntax Directed Editor"

The ABC structure editor. Structure-based editing for the ABC programming environment http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.694.3304&rep=rep1&type=pdf

design and implementation of syntax directed editor http://www.dtic.mil/dtic/tr/fulltext/u2/a212085.pdf 1989

A small contribution to editing with a syntax directed editor http://dl.acm.org/citation.cfm?id=808242 1984

Syntax directed program editing http://onlinelibrary.wiley.com/doi/10.1002/spe.4380130507/abstract 1983

A relational program for a syntax directed editor https://archive.org/details/relationalprogra00maclpdf 1982

On the usefulness of syntax directed editors http://bat8.inria.fr/~lang/papers/trondheim86/usefulness-syntax-directed-editors-19860616-18.pdf ~1980s

towards user-friendly projectional editors http://mbeddr.com/files/projectionalEditing-sle2014.pdf

12

## People who are interested in this kind of thing

2

https://eev.ee/blog/2016/12/01/lets-stop-copying-c/

https://eev.ee/blog/2015/02/28/sylph-the-programming-language-i-want/

Big list at the end of this: http://web.archive.org/web/20070621162318/http://mindprod.com/projects/scid.html

2

Joshondesign - josh marinacci (sacred cows)

Jake Brownson https://twitter.com/jakebrownson

2

from "prune" post

the `plastic` and `east-west` folks

Joel Burget

3

from the "general purpose tree editor" post

https://github.com/invaliduser

https://pcmonk.wordpress.com

2

Rules

before you talk about your cool new editor/IDE idea, spend some time with intelliJ. Also, spend some time with MPS

483

Categories of things

365

Full Structured Editors

9

4

Pretty developed?

lots of usability stuff, but lots of cool things

type inference & display

"proportional font" is not something I anticipated liking, but maybe?

http://kevinmahoney.co.uk/articles/structural-editor-prototype/

Screencast https://youtu.be/shLQw_ivtfw (2:25)

43

https://www.facebook.com/notes/kent-beck/prune-a-code-editor-that-is-not-a-text-editor/1012061842160013/

10

quantifiable goals

2

fewer keystrokes

I don't think this is super useful

2

fewer errors

100%

2

greater overall efficiency

? how to measure?

3

[I would add]

better navigation

better understanding / reading of codebase

4

Tree Transformations!

"Wrap" a statement in an if

"Unwrap"

create, delete, reorder nodes

11

various stuffs

TBD Node - the "?" waiting to be filled in node

2

"the editor should allow the user to build a tree by introducing nodes in any order"

dunno what this means

2

"A hundred or so transformations suffice for editing JavaScript"

typeahead for it

2

"With practice, pruning with the typeahead feels a little like just typing. However, all the "noise" characters, put there just to make the parser happy, like parentheses and curly braces appear automatically. Typeahead adds to the efficiency of editing, reduces keystrokes, and makes Prune more approachable."

they say not having parens reduces keystrokes, but I think that's actually not a super valuable goal

2

"validate that reducing the keystroke count was possible"

ummm yeah I really think this is a red herring

haha "programmers don't spend that much time manipulating programs copared to all the other things they do"

4

Learnings

tree transformations can work

eliminating the text editor, and just dogfooding, helped :P

yay formatting is a huge waste, don't look back

12

Future

2

target a tablet

:-1:

2

use a declarative language to define transformations

:t: hmmm interesting to think about

use a predictive parser :+1:

use jetbrains :/ eh

2

implement macros :+1: :+1:

let programmers implement their own sequence of transformations

2

reuse the transformations.

It seems like it should be possible to write a version control system that merges streams of transformations instead of textual diffs, potentially reducing the number of merge conflicts.

consider using machine learning to predict which transformation will come next :+1:

18

https://i.imgur.com/wvcduDk.png

Unfortunately it has a Vim-level difficulty curve and people don't realize how much time they currently waste on syntax mucking. This makes marketing kinda hard, even with a fully operational and well polished implementation. Fun fact: structured editing also works with non-programming structured text, like JSON, HTML and CSS!

3

:?!: Ultimately, I have to concur with the people calling out the lack of need; if my sustained average is 80 lines of code per day, I'm not being bottlenecked by my type time, but I am bottlenecked by typing errors that cascade to runtime. I would welcome seeing more modes that simplify specific, necessary-but-error-prone tasks like copy-paste-modify.

this is a super good comment

the structure editor has to be really clearly beneficial for refactoring, reading code

2

:?!: I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros right, on 1st attempt, becomes nearly effortless, once in that frame of mind. It's the think-design-code-test loop that is the biggest driver on my time/energy/brain cost. Not syntax conformance. Conformance becomes like a musician having played a certain instrument for enough years, you acquire muscle/eye memory for what note requires what finger/body/mouth positions/behaviors, nearly a one-to-one map, autonomous. Do agree that anything that enforces syntax correctness, upfront, is helpful for newbies, especially "forever newbie" use cases, the non-expert users.

structure editors allow more visualizations of the code! which would be a huge "a-ha" for people I think

9

:?!: a good example of the editing process that structured editors are better for: Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch. lineTo((10, 35), (20, 15)) ^ lineTo((20, 15), (10, 35)) Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the keyboard. Three or four seconds, and to me feels like using a blunt knife. And yet you are just moving one element down a list. You do it all day with parameters in a function, statements in a block, items in a literal list. Which is why it has a dedicated command in my editor: "Move down" (https://i.imgur.com/wvcduDk.png). It's a single key. Works in all cases mentioned, for all supported formats. I'm not saying a structured editor is for people who forget semicolons. It's for people who have to work with semicolons.

2

That's a lovely example. I was going to post that I don't like structure editors, but your example is two keystrokes in Emacs: c-m-F and c-m-T -- which I now (after 35+ years) realize is a structure editor. (one of the first things I worked on when I started at PARC was adapting an Emacs clone since I didn't like the Interlisp structure editor. Little did I know!).

yeah! emacs and vim are approximating this, but think if that was the full mode all the time!

2

someone claiming "Aside from that, years of user-experience research shows that modal editors are worse than the alternative (if you can hit one key, that means you can't type text in that mode; sorry vim-lovers, but it's true)."

I wonder if there actually is research showing this?

3

and I'm saying with a low-overhead deterministic-optimized editor like vim, and the right person at the keyboard, this can be done very quickly and accurately. and again, to continue your example, the hard part is not getting the syntax correct it's ensuring the resulting visual image -- your example suggests a vectory visual artifact ala OpenGL or SVG, etc. -- has the right shape and position. Syntax is something my brain/eye system just tells me, instantly, RIGHT or WRONG. our brains are great at this. I'm not saying syntax-enforcing keystrokes are a bad thing. I do think there are benefits to having a set of syntax-generic consistent keystrokes, like vim, across all the various syntaxes one has to deal with, day in and day out. If the only thing I ever had to edit was C files or JSON, that's it, nothing else, then yes having a C or JSON-semantic keystroke-restricted inescapable mode (with prompts, wizards, etc.) would be a help. (Which arguably is how all the big fat modern IDEs have evolved towards anyway.) But I'm very aware of the phenomenon where one can gain in the small but lose in the large. Local maxima, etc.

2

:!: another thing -> having the key strokes be uniform across different languages

which I think they really would be transferrable

> I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. I don't want structural editing because I can't remember the syntax of a language. I want it because I want to edit the code more efficiently. I don't know if I'll really be more efficient, but that's nonetheless what I want. People who use more plain editors like Gedit or Notepad++ might scoff at Emacs or Vim users. But if they think that power editor users use them is because they can't write or navigate text, they're really missing the point. The point is to navigate and edit text more efficiently.

10

looks pretty mouse-driven :( so not a super great interface

looks like haskell? but maybe written in ocaml? (based on the "ocaml structure editor toolkit")

oh wait - it's a custom language looks like. interesting

lots of tutorial videos

https://www.facebook.com/supereasy?fref=ufi

https://www.youtube.com/watch?v=w5-g0Hps6bA&feature=youtu.be

TODO read more lambda the ultimate

5

custom editor renderer using webgl apparently?

uses standard file organization though

collapsing code zooms it out

collapsing code zooms it out

does some input restriction - space does nothing, can't add a binop in an object key

6

uses CodeMirror (or ACE), and so text is still the fundamental construct, but editing is completely controlled so it might as well be full

alt+arrows for navigation between atoms n stuff

cmd+arrow moves an atom around, or for nagivating within an atom

https://www.youtube.com/watch?v=HnZipJOan54

5

https://github.com/Cirru/stack-editor

Clouditor https://github.com/Cirru/clouditor/

https://github.com/Cirru/cirru-editor

59

Structur-ed

50

Blog about http://programmingmusings.blogspot.com/2012/11/projectional-editor.html

This is the one who made (is making?) `projecturEd`

4

The term structure(d) editor is often used to describe editors that are cognizant of the underlying data structure that is being edited. I think this terminology is somewhat misleading in that it suggests that text editors are not structured editors. People might say that a text editor is not cognizant of the edited data structure, because the actual meaning is hidden in the user's mind. I think this distinction is wrong, because no matter how clever an editor is, there can always be an extra projection in the user's mind. The editor has no way of knowing what's in the user's mind. According to this view a text editor is a perfectly valid structured editor for the text document data structure.

hmmm

2

"a text editor is not cognizant of the edited data structure, because the actual meaning is hidden in the users mind"

Actually, I think the reason is that "the text will get parsed", and editing happens on the level of characters, and not on the level of the structured that the compiler will deal with.

2

It's called projectional editor, because it **provides its editing capabilities using bidirectional multistage projections between problem domains.**

fancy

:t: so there's definitely a distinction between "structured editors" and "projectional editors", in that I'd say one is a subset of the other. A structured editor tends to be a projectional editor with only one projection, which tends to closely match the look of a pretty-printed text version of the AST

2

For example, it should provide editing for XML structured documents in the same way as text editors do as far as the user is concerned. That is, it **should support invalid syntax, incomplete syntax, etc.** while still having all the benefits of projectional editors.

huh, this is something I don't agree with. I wonder what the point is

:?: I would love to ask this person about the "we should allow syntax errors" bit

4

:!: Examples of projections:

filtering - it may be used to focus only some parts of the document while the rest is hidden (e.g. show the chapter titles only from a text document, show some elements from an XML document, etc.)

ordering - it may be used to sort the content (e.g. sort the functions in alphabetical order in Java code document, sort the calendar events in chronological order, etc.)

grouping - it may be used to arrange the content into groups (e.g. group the rows of a table according to the value in the cells of the first column, etc.)

5

more projection example stuff

text - stylized text similar to word processing documents

table - two dimensional arrangements

tree - collapsible hierarchical drawings

graph - drawings with nodes and edges

hmmmmm so "projectional editor is really just a generalized REPL" hmmmm :/

**define domain**: data structures of documents, selections and operations that belong to a problem domain

6

:!: example domains

data structures - boolean, integer, number, string, pair, tuple, list, tree, graph, set, map, etc.

data formats - XML, JSON, ASN.1, etc.

programming languages - C code, Java code, Lisp code, etc.

text related - paragraphs, styled text, word processing with chapters, spreadsheet, presentation, graphics, etc.

databases - relational data, object oriented data, etc.

6

**define document data structure** it describes the possible states of domain specific documents. Here are some document data structure examples:

integer domain - an integer consists of a sequence of bits

string domain - a string consists of a sequence of characters

list domain - a list consists of a sequence of arbitrary elements

XML domain - an XML element consists of a list of XML attributes and a list of XML child elements, an XML attribute consists of a name string and a value string, etc.

graphics domain - a point consists of a 2D coordinate and a color, a line segment consists of two 2D coordinates, a color and a thickness, etc.

ooooh this is getting really interesting. trying to lay down the really general things about an "editor"

4

**selections**

string domain - a character position selection consists of a string reference and an integer in the range [0, length]

XML domain - an element range selection consists of a parent element reference and two integers in the range [0, child count)

Java code domain - a method selection consists of a method reference

4

operations

integer domain - bit negation operation consists of a bit selection

string domain - delete character operation consists of a character selection

list domain - replace element range operation consists of an element range selection and a replacement list document

4

primitive projection - directly between 2 problem domains

styled string to graphics - transforms a styled string to graphics document directly related to API calls

tree to string - transforms a tree of nodes to a flat string using delimiters and separators

XML to tree - transforms an XML document to a tree with attributes and elements being nodes

mk, so this is a really interesting theory of projectional editors.

I certainly don't think I'll go this direction (with the focus of converting between all these different projection domains), because I think the funtamental benefit will come from just treating our code as a structure instead of a lump of text. But super interesting anyway.

written in common-lisp

last commit in Feb (9 months ago)

Shows many different languages interleaved with each other

"Priojections" different reversable presentations of the data

https://github.com/projectured/projectured

http://projectured.org/

12

3

last updated: 2012

https://github.com/mthiede/concrete

BUT the author commented on a github issue a day ago, so is still there

4

Can create custom html+css templates to display a given syntax node. super cool

same editing commands apply

editing keyboard experience seems very different from text editors -- have to first define the "binop" then the first el, then the second.

http://vimeo.com/9164866

InfoQ article https://www.infoq.com/articles/dsl-concrete-editor

36

interesting display choices (still all text though)

haskell-like (hmm it does look like it's a new lang)

rename is supported

5

Summary

No syntax errors or name errors

Type errors are localized - static typing becomes friendly rather than scary

Type inference works even in intermediate states

Type driven editing reduces keystrokes and cognitive load

26

Lamdu HN https://news.ycombinator.com/item?id=6964369

7

Chris Granger on the problems presented to structured editors

For those new to this world and wondering why this stuff doesn't seem to exist, one of the biggest problems with projectional editors is handling the translation problem.

How do you reconcile changes in your representation with changes in the underlying code?

Can you reliably parse handwritten code into your AST representation write it back and so on without any loss?

What happens with handwritten styles that maybe don't fit into the projection's way of viewing the world?

What if I know a better way to output the AST than you?

It's also particularly difficult dealing with change over time since there are no true unique identifiers for bits of code.

4

The main problem with structured editing is that it requires programmers to write code in a certain order that is often goes against their "flow;" enforcing a rigid flow is a huge usability negative. Even without structured editing, we see cases where increased flexibility improves flow; e.g. in dynamically typed languages. Unfortunately, improvements in flow often lead to reductions in feedback (e.g. via static typing). I'm in the camp where the programming experience should be considered holistically. The IDE is a part of that experience, and so language design should occur concurrent with IDE design. With some smart incremental compilation magic along with language-specific rendering in the IDE, we can build programming experiences that provide the benefits of structured (and projectional) editing without the flow costs. Or at least, that is the premise of my research :)

3

I agree that structured and visual editing paradigms have failed. But ultimately all you're saying here is that structure approaches haven't offered enough positive to offset the cost of learning them. That may be true but it would be good to know why. My guess is that the data structures generated by the text of programs is just too varied and complex for any visual representation system to be of use. The programmer is interested in the final structure of their application and every intermediate one. Creating a program to represent those visually should be harder than implementing the application. Multiply that by every application that could exist.

> But ultimately all you're saying here is that structure approaches haven't offered enough positive to offset the cost of learning them. That may be true but it would be good to know why. No, I'm claiming that bad flow, even after you've learned and adapted to a structured paradigm, needs to be solved directly. Even if you can provide really great feedback, the bad flow will still exist and cause inefficiencies not offset by enhanced feedback, which is aimed at an orthogonal set of problems. Edit: a good analogy might be between agility and armor in a tank. You can obviously make the tank more survivable by improving either one, but its overall usage becomes more limited when emphasizing one feature at the expense of the other.

:!: so make sure that flow is not compromised

2

This stuff has been done forever, and it's been "the next generation" forever. Things like **separation of structural editing from the language specficness of an AST** while still providing a sane and useful editor are paths that have been tried before. Not that this means people shouldn't try, but as you can see from just these two links, there has been a lot of research and effort put into this area in general. This is an area where **i'd read a lot more than i'd sit down and code**, because a lot of smart people have been this way before. Case and point: Susan Graham (and maybe Tim Wagner), who lead the Harmonia project (and many projects before that), is basically the goto person in the world if you ever wanted to know anything about incremental analysis of programming languages (she also helped write gprof, among other things)

:t: hmm so this is "translating multiple languages to the same AST representation"

2

An approach that might work with existing languages is: To use a traditional flat editor (not a structured editor), but show inferred information around the code. I am thinking of visuals that are akin to http://explainshell.com/ but a lot more compact. The inferred information need not be shown always; it could be shown dynamically based on the user's context (current line, current function, etc)

:t: this just sounds like an IDE

2

this 2004 post by oliver steele remains one of the best things i've read on the topic: http://www.osteele.com/posts/2004/11/ides key quote: "In fact, the most powerful languages may initially have the least powerful tool support. The reason for this is that the language developer, like the language adopter, has to make a choice: whether to dedicate limited development resources towards language features, or towards tool support."

:t: hmmmmmmm I feel like this might be a false dichotomy

2

The real gem in lamdu compared to LT, Subtext,MPS etc is the integrated versioning, IMO. Far too long have we been doing snapshot-based development. I hope this is a language feature and not just an IDE feature, however, so that the evolution of the program is expressed within itself

:!: oooohh integrated versioning! I should check this out more

2

Very cool but I am afraid this is geek candy that would not fly for mere mortals. When you say next-gen IDE do you mean for a certain class of developers? The problem with these type of development tools is that it moves your brain from thinking in terms that of a human to thinking in a very structured way more attuned to machines. This is a problem with functional programming in general, it is fundamentally anti-human, people don't think functionally but rather procedurally. Full disclosure here, IDE maker so I have skin in this game :)

:!: moving from the way himans think? :D what does that even mean, do we naturally think in strings of code?

2

Granted, if a human wants to describe a physical process, they will use procedural language. But computers are primarily about information, and we think about information in terms of relationships. That's exactly what FP is about: expressing computation in terms of relationships.

:t: oooh I really like this framing

2

No, they didn't. They invented a syntax two milleniums ago, optimized for use-cases of those ages, using alphabets of those times. Thinking in greek symbols is not helping anyone think clearly. It's just more confusion, because now suddenly, i can't type or phrase a relevant question out loud, until i get a greek keyboard and learn the proper pronounciations of the greek alphabet. The notion we should just stick to a notation and conventions optimized for a different era, a different culture, a different alphabet and a different writing tool (paper), is ridiculous. Do NASA scientists calculate speed using knots? Or power using horse power? They do not. Math is to computer science, what classical music is to pop music. A historical relic that stopped having economic and cultural value beyond being a mere status symbol.

:!: hahah actually classical music is awesome

136

17

https://news.ycombinator.com/item?id=9512955

2

for me good IDE feels like semantic editor. I'm inclined to believe that text based editor can have all the good features of semantic editor and avoid most of the bad ones.

:t: gonna address this directly

I suspect that what he has in mind is that any value within the Unison language can appear on any Unison node, transparently. Instead of picking out exactly which fields you need and then creating new JSONObjects or protobufs for them, just send the whole variable over.

On the surface it sounds interesting, but I don't really buy the idea that programming is terribly limited by the quality of text editors. Even "basic" editors like vim and emacs can almost instantly catch most syntax problems, and IDEs like Eclipse and Visual Studio are great about complaining if you make a mistake. In my experience, these days relatively few problems come from language syntax errors ... most problems come from mistakes in logic, poor systems integration, or incorrect validation of input data. Not sure how Unison will solve those challenges, but to be fair maybe that is out of scope.

One of the mantras of functional programming is get your data structure right, and everything else falls into place. As an experienced functional programmer, I see this in practice every time I program--even a slightly "wrong" type pollutes the code dramatically. The idea then with structure/tree/semantic editors is two-fold. First, text is obviously the wrong the wrong data structure for programs, so even if people manage to provide fairly good support with the "modern IDE", the effort it takes is staggering. And still details like files, character encodings, god damn tabs vs. spaces, and terminals leak through. One can't help but wonder how much farther they would get were their efforts directed more efficiently. Look at this https://github.com/yinwang0/ydiff for example, blows text diff out of the water. Second the idea is maybe text is the "wrong data structure" for programmers too, not just tool-smiths. I admit there are bunch more psychological/neurological aspects that make the answer less obvious. But I see no reason why not to keep an open mind until a polished tree editor exists for empirical testing. Even if text is in someways better, the improved functionality a tree editor offers could offset that dramatically.

3

> That's one thing Unison is trying to fix. Is that actually a problem? If you're never allowed to input incomplete/broken code, then the way you program is very limited. Often I like to start writing a function, get to the point where I realize I need another function, write that one, and come back to the first function. In an editor where only working code can be input, you can't do this style of programming, which almost rules out exploratory programming. You have to more or less know what you're doing from the start.

:!: ah the answer for this is probably type inference (ocaml style) where function types don't have to be declared ahead of time

also allowing return types to be errors (e.g. have an implicit `failwith "incomplete function"` at the end of the function)

2

If this video < http://pchiusano.github.io/2015-03-17/unison-update5.html > is an example of this, then yes, it does look annoying and inefficient. Now I'm not sure if I understand exactly what he's doing here, but it looks like something along those lines: rather than inputting what he wants directly via the keyboard, he has to choose a pattern (like variable-operator-variable) from a drop-down list, and then tab between the fields to fill in the pattern. A poor analogy might be the difference between speaking words verbally to form a sentence vs. shuffling through a stack of index cards to find the right words to arrange on a table to form a sentence. The latter would be useful if you were just learning a language, but once you know how to speak it, that would be an enormous waste of time.

:!: yeah that sounds a lot more annoying ; a usability problem

4

From what I can tell - users love freedom and computers hate them. Why else do you think people still stick to text editors ? A plain text editor is probably the most unconstrained environment there is. So, what is the best way to find some sanity in between? If you ask me, I would say that the main way to transform or change programming would be to remove as much constraint as we possibly can from the user. Let me crap all over the place - and you as the environment make sense out of it. That is why we are building Dhi ( http://www.dhi.io ) - An AI Assistant to help you build user interfaces. We are building it in such a way that the user has complete freedom to say whatever he wants to say and we ( perhaps sometimes even with the help of the user! ) plan to make sense of it. THAT is the dream.

I'd say that users like constraints too

immutable data

VIM modes

2

It may sound counter-intuitive, but if your editor makes it impossible to type incorrect statements, it'll be really hard to learn/use/hack. Play is an important (essential) part of learning. That said, I think there needs to be more experimentation in this area, so I hope you're successful.

:?!: got to show how "play" can happen in a structured editor

18

https://pchiusano.github.io/2014-09-30/punchcard-era.html

traditional programming is compile, fix compiler errors, repeat

with REPLs we gain some benefits back, where you can have a feedback look, a discussion w/ the env

but then you move to your file and it's ultimately separate -- even if you can do things like "try evaluating this snippet" from your text editor (emacs + slime)

constrain the editing UI to only allow the creation of programs that typecheck

5

Challenges of this

wouldn't have a "cursor" where you can add arbitrary characters

how do you respond to invalid input?

how to navigate around the document?

plain-text programming gives people a feeling of directness & control

8

Advantages of SDE

no parser to write

no tracking locations ( :t: not actually true, there are tree locations now)

trivilly ensure well-formedness

can render as stuff other than text

large-scale edits can be described as a set of refactoring combinators rather than manual text munging ( :| IDEs do this already to some extent)

2

usable by children & newcomers to the language! like bowling lanes with bumpers

:t: I would submit that *synax is not the hard part*

100

Blog posts

5

Concurrent Version control + editing

And there’s a deeper question—what is VCS really “about”? Perhaps VCS is really about several distinct concerns: Supporting concurrent development Maintaining history, for lots of reasons, including auditability Providing commentary on edits, and possibly on groups of edits Having a notion of logically related branches of development

So it seems like the "waterfall effect" of edit propagation would get reeeally out of hand. A single-line change to a function could cause ripples throughout the codebase, and that would happen for *every* edit to that function. Wouldn't that be a bit much?

2

"Semantic Version Control"

I’ve been really interested in the idea of semantic version control for a while, in which the unit of edits is not text diffs or even tree diffs, but semantic edits that map more directly to programmer intent. So, an edit might be ‘swap the order of these two function parameters’ or ‘rename this function parameter from x to x2’.

35

Designing a fluent interface to a semantic editor http://unisonweb.org/2015-10-14/fluent-editing.html#post-start

2

Textual editing gives a feeling of directness and control. There’s basically a one-to-one correspondence between the editing inputs (type the ‘a’ key), and the default rendering of the model in response to those actions (the letter ‘a’ appearing in the editor). Like drawing a picture, painting, or sculpting clay, the user feels like they are creating via direct manipulation, without needing any deep training to get there. This is a good feeling to strive for even if raw textual editing isn’t the medium used.

Manipulating text to write programs might feel very direct, but only for someone who already knows how to type quickly, and who is fluent in understanding the textual representation of programs. And actually, much of text editing in tools like Vim or Emacs is very indirect. One learns a bevy of different key combinations and shortcuts to produce various effects, and it’s only with time that these actions are so committed to muscle memory that use of the editor starts to feel like direct manipulation.

8

Navigation

For the editor navigation controls, there are currently just a few actions: up, down, left, right, expand, contract, leftmost, and rightmost. (I’ll add search at some point too, and that’s probably it.)

This action set can efficiently encode any navigation in the editor, and leaning on the existing geometric intuitions the user has works well.

Easy wins here are using the arrow keys to specify these movements, leveraging the existing encoding most users already have well established.

(And also supporting home row hjkl-style navigation is easy too.)

The one arbitrary part of the encoding requiring new learning is the expand and contract actions.

Though these actions are easy to understand, there’s no standardized keyboard input for them.

But since they are somewhat analogous to up and down, a good default might be + and +.

8

Navigation actions

3

open path - Opens the currently highlighted node for editing, which brings up the explorer.

The editor is always in one of two modes - editing, or navigation.

When in the navigation mode, the user has access to the navigations actions discussed above.

2

close - Close the explorer and transition back to navigation mode, replacing the highlighted node with the expression selected in the explorer.

I’m using the word “expression” more generally here, since we should be able to do the same sort of editing whether we are replacing a subterm of a Unison term, or modfying part of a type or type declaration, or editing the name of a symbol.

cancel - Like close, but leave the highlighted expression in its original state.

filter - Manipulate the contents of the explorer, by typing a query to filter down matching results, or by using the arrow keys or mouse to change what item is selected.

4

Various refactoring actions which are guaranteed to keep the program well-typed. For instance:

Replace the current selection with its evaluated result. Example: 1 + 1 gets replaces in the editor with 2.

Replace the current selection, x, with _ x, wrapped in a blank function call.

Introduce a new binding at the current scope. That is, x becomes let z1923 = _ in x.

3

Various actions which aren’t guaranteed to keep the program well-typed.

For instance, replacing the current selection f with `f _`, which is only safe if f is a function of some sort.

Or replace the current selection x with x + _, which is only safe if x is a number of some sort.

2

This ability to search for actions seems to raise the need for a third mode.

Or does it? Proliferation of modes is complicated and makes the UI harder to learn. Better to just co-opt the explorer for this. When the explorer comes up, **applicable replacement expressions as well as actions** will be shown, and filtering will search for both.

6

The final set

A small number of navigation actions: up, down, left, right, leftmost, rightmost, expand, contract, and (later) search.

A single action, open, for transitioning from navigation mode to editing mode.

A cancel action, for transitioning from editing mode to navigation mode, with no effect.

An accept action, for transitioning from editing mode to navigation mode, with the effect of modifying the current selection. This is used for selecting both actions (like refactorings) and expressions for substitution.

An accept-and-advance action, which might act like an accept, followed by a right movement, followed by an ‘open’.

:t: hmmm so I'm not super a fan of this setup; I want to be much closer to the keystrokes of editing text that people are used to

15

Semantic vs Plain text - editing experience http://unisonweb.org/2016-03-16/semantic-vs-text.html#post-start

:-1: don't need to type full identifier names

don't need parenthesis (fine, but make sure it's displayed in a way my mind can parse)

11

What do programmers actually spend their time doing?

adding imports to the code to be able to resolve names

doing google / hoogle searches to find the name / signature of the function you want

looking up & reading docs

compiling, reading type errors, fixing type errors

large-scale refactorings ("add an extra argument to this function")

small-scale refactorings ("make this chunk of code a separate function")

3

filling in boring chunks of code whose implementations are at least partially specified by the types

like what a theorem prover might be able to automatically deduce

:t: hmm is this really very common?

formatting code

Fewer context switches!!!

13

Top-down vs Bottom-up - when do you not want to worry about types first?

Another interesting aspect of this example is you can imagine the thought process of the author: “I just want the wrapDomEvent function with the arguments in a different order”.

Programmers use this style of reasoning quite a lot, even in typeful languages.

6

Refactorings like

switching the order of arguments,

pulling a subexpression out into a let binding,

abstracting a subterm into a function parameter,

beta or eta-reducing an expression,

and many other program transformations

can be conceived of without really considering types at all.

More generally, when you **abstract over parts of your implementation**, you aren’t necessarily reasoning primarily in terms of how this will affect types. You may be primarily reasoning in terms of **where you want information to be specified**.

Abstracting over a concrete value being used in a term is a way of altering where that information is specified, and the programmer conceives of it primarily as such.

Yes, moving around where information is specified affects the types of functions along the chain of dependencies, but this is actually less interesting to the programmer and not the focus of their attention.

15

Arguments for static typing https://pchiusano.github.io/2016-09-15/static-vs-dynamic.html

6

Advantages

A large class of errors are caught, earlier in the development process, closer to the location where they are introduced.

The types guide development and can even write code for you—the programmer ends up with less to specify

One can refactor with greater confidence, since a large class of errors introduced during refactoring will end up as type errors

Static types can ease the mental burden of writing programs, by automatically tracking information the programmer would otherwise have to track mentally in some fashion.

Types serve as documentation for yourself and other programmers and provide a ‘gradient’ that tells you what terms make sense to write.

7

Drawbacks

Like any formalism, types require some investment up front to become fluent in.

Type errors are frequently poor.

Static typing is a constraint on your program’s structure. How limiting or liberating these constraints are is up for debate, but some people will argue it’s a big deal.

Some tasks, especially around generic programming, can be very easily expressed in a dynamic language, but require more machinery in a static language

It can be difficult to assign static types to some programs, and learning how best to carve a program up into types is a skill that takes years to master

To put this last point another way, with static types, you have to make more choices, and you may have to make these choices at a point in time where you’re unsure how to decide, or when the choice feels distracting.

My thought - static (expressive) type systems help encourage you to *think about the types*, which can be really clarifying and lead to much better code

7

Semantic Editing

The other model I’ve experimented with is simply getting rid of parentheses to control editing entirely. Instead, one uses the arrow keys or to navigate, and there are two actions to accept and continue, one indicated by and another indicated by . Say accepts the current completion and advances to the next sibling of the current node, and accepts the current completion and adds a new child to the current node and moves the editing cursor to that.

2

In Unison, terms are uniquely identified by a nameless hash (more on that in a later post) and don’t live in packages or modules.

:t: I expect they will find that organization is actually a useful thing

3

In raw text editing, it’s necessary to disambiguate references with explicit imports. Some IDEs will automate this for you, but the model is the same; the presentation of the program must disambiguate user intent, leading to 50 lines of imports at the top of every “file”, where its often arbitrary how codebase is split up into files. In a semantic editor, we can dispense with the ceremony of imports and instead let the user disambiguate at the point of reference. Here’s a very simple proposed interaction: Upon opening a node to edit, we search local scope based on the search query. If the search query starts with "?" we include global scope as well. If the number of matches is too high, we display only the count. Notice that unlike using something like Hoogle “manually”, we don’t have to enter the type, since the editor knows the type of the current edit location and can supply that information for us! Thus, we just focus on specifying whatever metadata we’d like to search by.

2

:t: "where it is often arbitrary how the codebase is split into files"

Yeah organizing things is actually important I think.

9

More interactions

In the explorer, typing a space followed by an operator accepts the current completion and opens a fresh explorer with the operator prefilled. You can see this in the video, where 1 + becomes (+) 1 `_`. In the explorer, typing two spaces accepts the current completion and moves the explorer to the right. You can see this in the video. Typing ‘s’ steps (linking + 1 beta reduction) the selected expression. Typing ‘e’ evaluates the selected expression (to weak head normal form). Global search is now enabled by default in the explorer. In the video, I look up the identity function. Notice that the completions are aware of the admissible type. When we go to fill in the second argument to +, we see the fully saturated version of (+), applied to two arguments, `_` + `_`.

Typing ‘a’ applies a function to the selected expression, so 42 becomes `_ 42`, and the focus moves to the `_`. Typing ‘r’ does one eta-reduction, so x -> f x becomes f. Terms which are ill-typed but which match the search query are displayed in the explorer along with their types (but are unselectable of course). Builtin functions for concatenting strings. Stepping works fine under lambdas. For instance, we can simplify the 1 + 1 in x -> f (1 + 1) to x -> f 2.

:t: feels like these actions are on the super-PL-theory side of things, and might not actually be useful?

5

About spreadsheets

Spreadsheets have a largely nonsymbolic representation of programs. The only symbolic representation used is the simple expression language, which people can easily learn as it consists only of constants and function application. Of course, every spreadsheet program has some ad hoc language for defining new formula, but that’s outside the usual spreadsheet model and gets used very rarely.

We can think of the spreadsheet as a limited kind of application-building toolkit. It supports a form of interactivity, in that we may select a location for editing, and updates occur in response to these edits (conceptually no different than any other application, be it Photoshop or Twitter). There’s no separate step of ‘running’ the program and we’re encouraged to consider the UI as just a way of viewing a program, rather than a separate artifact produced by a program. See viewing a program as a UI.

The user can easily construct functions that manipulate sequences in an inductive fashion, considering only concrete inputs. For instance, the cell A2 takes the value = A1 * A3 + B$7, and the user drags to extend the definition to build a whole sequence. Of course, a programmer has no trouble generalizing this sort of thing and just writing a step function that uses symbolic inputs, but it requires less learning to do things the spreadsheet way.

Lastly, and this might seem dumb, but a 2D grid as a template is actually a surprisingly nice starting point for a lot of computing tasks and layouts. In terms of approachability, it is much easier to modify an existing template than it is to start with a blank canvas and create entirely new content. A blank canvas requires that the user have a vision of what they want to create, which they execute on by understanding the means of abstraction and means of combination. In comparison, the ‘modify a template’ mode of spreadsheets lets the user get away with just reacting to what’s on the screen. Bret Victor talks about some of this in Learnable Programming. I won’t argue here that one modality is inherently better than the other, but part of the appeal of spreadsheets is they do support the ‘create by reacting’ modality better than traditional programming.

4

makes a distinction for Frames (statements) and Slots (expressions). Slots are more free-form, but htere's still some structure here

> Isn't this just structured editing all over again? Didn't we abandon that in the 80s/90s? The ideas are similar to structured editing. Structured editing wasn't actually a bad idea, it was just poorly executed. In the intervening 25+ years, computing has gained advanced display/GUI capabilities, and we've learnt a lot about the usability of software. So you can think of this as a fresh attempt at structured editing. And really, this isn't the first attempt; Scratch and similar languages have already showed that these kinds of ideas can work.

scratch https://scratch.mit.edu/

13

MPS https://www.youtube.com/watch?v=PPU99grx28E

state machine language

state machine language

8

Things that are cool about MPS

so many things

the "alt+enter" menu w/ autocomplete for minor refactorings

4

the way that not all information is represented in the text representation -> there are side panes that show more information and are also editable.

thisi is like the DOM inspector in Chrome, where you see the dom nodes, and then also have the style editor

I'm not 100% sure that this is good (wondering what things should be hidden by default but editable upon "unspection"), but it seems like a powerful concept

:i: this could be super great for tests! You focus a method, and if there's an associated test then it gets shown off in a side pane or something.

DSL editors for making the DSLs

7

Cedalion https://cloudalion.org/blog/

https://www.youtube.com/watch?v=Lb3x5lKeIfA

Eclipse plugin

interesting structure editor

This is super fascinating

uses predicate logic

38

Mixed Structured Editors

8

the creator: https://www.facebook.com/antonin.hildebrand?fref=ufi

embedded in atom!

also has strong "literate programming" feels

not touched in a year

2

inspired by "Flense" https://github.com/mkremins/flense

doesn't appear to be much to see there...

4

does a lot of work to maintain formatting stuff, has a bunch of shortcuts for structural stuff

maybe look to it for ideas on what transformations to do?

or definitely if I were gonna to something w/ haskell

3

interesting compromise, very lisp-specific

you're editing raw text, but parinfer does lots of auto-editing to ~ensure syntax consistency

11

7

editing commands

wrap current thing in ( or "

delete a synatic atom

slurp + barf => bring sibling atoms into an s-exp (or move them out)

replace outer s-exp w/ current s-exp

split / join s-exps

take current s-exp, wrap it around the enclosing s-exp

3

movement

to end of enclosing s-exp

to start of enclosing s-exp

10

https://www.youtube.com/watch?v=dYbxvRLpEUY

very similar to iPython notebooks

but the code is a hybrid structured editor, where the block-level stuff is structured, but the code is largely loose

the `inline console` is interesting though - it's a blob of GUI in the middle of loose text

yeah, so you can insert arbitrary "visual" stuff at any point in your loose code. Super cool

e.g. visual tables can be embedded as a variable initializer

:!: cool ideas of "what visual things can we use that are better representations of coding construct than a pretty-printed AST"

33

"Visual elements" / notebook

25

2015

not structured - still text

BUT includes graphical elements via CodeMirror plugins; can replace some swaths of text with a graphical, interactable representation

20

References

Barista : 2006

2

"Design Principles for the Enganced Representation : 1986

http://www.diku.dk/OLD/undervisning/2001f/f01.639/baecker.pdf

12

Experiments in Code Typography : 2014

http://web.archive.org/web/20160513144534/http://research.microsoft.com/en-us/projects/liveprogramming/typography.aspx

8

Main thoughts

blocks w/ left borders

still need parens for precedence, function calls

pseudo-ligatures are fun

:!: digit suffixes are subscript!

hmmm snake_case underscores are rendered as gray squares... weird

the "@" prefix anywhere means "log this"

metatext == tooltipy things below warnings, errors, or to log values

“the most effective debugging tool is still careful thought, coupled with judiciously placed print statements”

4

Expressive programs through presentation extension : 2007

http://www.cs.ubc.ca/~ade/research/ade-aosd.07.pdf

render a visualization of a finite automaton

4

haskell IDE http://haskellformac.com/

3

looks a ton like playgrounds (e.g. ipython notebook, lighttable) for haskell

3

light table

inspiration post http://www.chris-granger.com/2013/01/24/the-ide-as-data/

https://www.youtube.com/watch?v=V1Eu9vZaDYw

46

Getting away from ASCII-in-files

20

Eve http://witheve.com/

new language

literate programming! So you write blocks of text & blocks of code

a table of contents shows up in the left bar, based on headings & subheadings in your "documents"

fascinating idea for code organizaton.

You can check/uncheck items from the sidebar to show/hide sections of a given document.

a document === a program

if you check/uncheck a heading, all subheadings under it are also shown/hidden

super interesting ideas

3

Code execution

is order independent (due to the language design)

you can also enable/disable code snippets

2

Good parser errors

2
magic wand mode

magic wand mode

"magic wand mode" where you can click on a rendered HTML element and see information about it

"An IDE like Medium, not VIM"

inline visualizations

inline visualizations

4

Conception-go https://github.com/shurcooL/Conception-go

last commit Oct 2016

8

Conception https://github.com/shurcooL/Conception#demonstration

this example has structured text as well tho

this example has structured text as well tho

this looks suuuuper cool. Would love a view like this for notablemind

interesting "canvas-like" approach to organization

contents of "code" blocks are raw text

BUT has "flow-based" programming cool stuff

also gui elements

11

leo editor http://leoeditor.com/

blog post about http://markdblackwell.blogspot.com/2011/07/installing-leo-outlining-editor-on.html

9

HN https://news.ycombinator.com/item?id=7843907

> The other problem is that it's not Vim. I also have this problem when trying out any other text editor. It's actually quite annoying because every other text editor I try is often much better than Vim at everything it does except editing text.

The time is ripe for a tool that integrates knowledge management and development with this "linked outline" structure; it's an upgrade over the classical folder-based storage of files.

There have been previous attempts to create integrated editors for semi-structured information both from the software (Code Bubbles) and documentation (Haystack project, Chandler) perspectives. Machines are now powerful enough for them to become useful and responsive (as these environments consume huge amounts of memory).

2

For such a tool to become widespread though, it will need to be based on user-friendly design, and be able to share content on the web. Evernote and Workflowy come to mind as tools with those properties, but they don't handle code execution; and reactive, live programming tools like jsfiddle don't allow for outline-like structuring. It would be great if such a tool was also Open Source, but that's unfortunately not a pre-requisite for success; I imagine Google or Apple will be the first to build such development environment, or to buy a start-up that build it and turn it into an standard.

:?!: aha notablemind!

I broadly speaking applaud the idea of breaking code into code-units which are independent of a specific file hierarchy and tagged with meta data; then reassembling them as a pre-compile / pre-run step.

The way it does that is by making 'clones'. So for example, if you have a long program that you find a bug in then you take the node with the buggy code (usually a few lines, maybe 10's of lines) and you 'clone' that node to the spot where you have your bug report or list of tickets or whatever. You then describe the bug, the fix and modify the code (which will modify the original code as well), or you modify the original code leaving the clone as a 'living pointer' to the code to document the location where the bug was found. You add the unit test as another node right where the bug report lives. The 'thin' model (where you import external files without actually having them present in your outline) is a variation on this theme, another way of doing it is to have the code present in the outline itself and then to export the code whenever the document gets saved. Both methods have their pros and cons. The biggest con in my opinion is that leo use is not widespread enough that you can expect to collaborate with someone else like this. That means that if you post your project on github or if you share the code with a fellow coder that all that Leo mark-up is wasted. This also likely does not play nicely with version control but I haven't tried that particular scenario myself (I just dump the whole tree in git or subversion and I work on most of this stuff on my own anyway).

2

SmallTalk

smalltalk image is a serialization of the whole system - all objects, data, etc

15

Not enough info

3

Grasp.io http://web.archive.org/web/20160413014558/http://www.grasp.io/

lol looks lke they died

sooo looks like this would have been cool / had a bunch of neat ideas, but I can't tell if they ever did anything

4

Lively4 projectional editor

not really sure what's going on here....

https://github.com/LivelyKernel/lively4-projectional-editor

lively web https://lively-web.org/welcome.html

4

random https://github.com/wdblair/overture

last edit Feb 2016

no indication of what it is.

doesn't look like it's a structured editor or at all related

Projucer http://www.rawmaterialsoftware.com/viewtopic.php?f=12&t=9793

2

https://github.com/pshc/archipelago

2013 last edit

24

Other stuff - blogs

2

Structured python editor http://glyph.twistedmatrix.com/2008/04/structured-python-editor.html

doesn't really say anything new

SO question about projectional editors http://stackoverflow.com/questions/9101332/projectional-textual-editor

2

Exploring the deep structure of code http://www.infoworld.com/article/2668520/application-development/exploring-the-deep-structure-of-code.html 2005

not super interesting

8

Structure editors, IDEs, and another Lisp flashback http://bannister.us/weblog/2005/structure-editors-ides-and-another-lisp-flashback 2005

4

things compelling about a structure editor example [subtext demo]

sample values

live computation

highlighting of dead code

2

"I do not see the java source as "hiding" the deep structure of the program"

hmm ok, so this is in response to the article "exploring the deep structure of code"

A significant pragmatic problem with projectional editing is the fact that there is no generally accepted format for the storage representation.

2

programming language checklist http://colinm.org/language_checklist.html

mostly, the "you seem to be under the impression that syntax is what makes programming hard"

5

instant C# http://ermau.com/making-instant-c-viable-part-1/

inspired by "inventing on principle"

wanted this for C#

Roslyn - a tool for analyzing C#

syntax rewrite, takes `int x = 5` into `int x = LogObject("x", 5)`

bret victor "inventing on principle" https://vimeo.com/36579366

wiki https://en.wikipedia.org/wiki/Structure_editor

https://groups.google.com/forum/#!search/I$27m$20the$20sacred$20cows$20guy/pdxfunc/eBLqHstoknY/FHelmjS_FLoJ

Augmented programming! lots in here https://groups.google.com/forum/?fromgroups#!forum/augmented-programming

373

Blog posts, Forums, etc

35

Joel Burget - Beyond plain text http://joelburget.com/plaintext/

10

https://news.ycombinator.com/item?id=9495493

2

:?!: Right now we have structured tools with easy learning curves but low ceilings, and raw text tools with high ceilings but with a learning curve like being punched in the face with a brick wall. There is definitely room to explore in between the two.

:!: Love this quote :D (about excel, etc)

2

:?!: It's not a solved problem if your project is gigantic or if you're doing cross-platform development and don't want to or can't use the build system of the IDE or if it's C++. To me solving the problem has a higher bar - you should be able to open a large project for the first time and have usable intelligent editor support within a second. I'm even okay with the results of autocomplete being incorrect (to a degree) if they are fast. I think IDEs make the wrong tradeoffs. They require you to use their build system and insist on parsing all the code in your project before providing anything useful. And guess what none of the IDEs that I tried for C++ provide something as basic as a fuzzy file finder by default. Most don't even have plugins for that and those that do have very bad and slow implementations. For me something like Sublime Text with a few plugins works great. And before anyone goes yada yada about semantic autocompletion and all that - you can get that too at a very cheap cost - look at YouCompleteMe for vim. For project wide searching I find it easier and more reliable to use grep (or git-grep, ag, ST built in search, etc.) than relying on the IDE's find symbol functionality.

dunno if I'm going to address this person's stuff...

:?!: an argument for a "two-paned view" I think the author has made an interesting point, but I would add that "time has come" to, not abandon text tools (which I don't think has worked; I think the trend is going away from Excel to R and python+pandas, in data science etc), but have a hybrid system, where the text representation of the "view" is visible to the programmer all/most of the time. For example: - we either have plain text "LaTeX" editing where we edit out document/source "blindfolded", and only get to see the result when we compile and view the pdf. - we use a WYSIWYG tool like Word (and some WYSIWYG LaTeX editors) where we stick to the view and are scared (sometimes it's impossible) to dig into the text representation - what we need is something like a hyprid, where a "view" line, and a "text" line are interweaved, or "view" on left side, and "text" on right side. And we could edit any of the two ways, and the other should update. I've been thinking along these line for quite a while, and if I get a change I intend to create some kind of system based on that.

2

:?!: This article makes exactly the same mistake that pretty much everyone else suggesting programmer tooling beyond plain text has made: assuming it has to be either or, that if we want more sophisticated tools that use a more complex representation, we have to give up text. The suggestion is a nonstarter. Network effects alone would prevent the world making such a move, and it's a good thing, because the loss wouldn't be just a particular existing tool, **it would be the entire universe of tools that work with text**, that the world has spent decades developing, most of which any individual has never even heard of, let alone thought about how to replace. It's also completely unnecessary. If you want a tool that lets you view and edit your code in a fancy table format, you can write one. All it needs to do is parse the existing source code into whatever internal format it wants and write it out again afterwards. Yes I know the author criticizes parsers, but really, writing reliable parsers has been done often enough to make it clear that it's a solvable problem. And would it not be better to have some of what you're looking for in an actual tool than all of it in an imaginary one?

:!: I'll need to make sure I address this

2

:?!: interesting side on "we won't need parsing" OK, let's talk about parsing. The article claims that parsing isn't necessary with structured editing. We're working on some abstract data structure representing our language's syntax. This might be an AST, like any programming language in common use today, or maybe in the future we've thought up some better way to represent programming languages within the compiler/interpreter. Since we're working directly with the AST or whatever, we don't need to parse! We just do whatever actions the programmer wants do over on our data structure. Now, let's talk about how parsing works in your language of choice in 2015. We're going to take a string, and we'll turn it into a representation of our program. If we're lucky, our language implementation isn't awful, and our parser will be a function from some sort of Unicode-encoded text into an AST. OK, maybe our input is ASCII or some other text encoding, but the point is the same. Either way, we're taking some keypresses from the programmer, and turning them into a data structure representing the program. Let's abstract a bit. Maybe in the future we don't use keyboards. Instead, we have whatever peripheral you like. This peripheral is capable of sensing some sort of action from the user, and turning it into actions within the computer. So now, our parser is a function from some user action to a data structure representing the program. This sounds an awful lot like "we just do whatever actions the programmer wants do over on our data structure". The question is, how do we figure out what the user wants? The answer is, we parse it! It doesn't matter if we're parsing text or not. We will always need some way of determining the programmer's intention from the signals we get through their peripheral device. Viewed through this lens, the camera requires a parser just as much as the keyboard does, just as much as the mousepad does, just as much as the microphone does. We will always need a way to convert the unstructured thoughts of a human programmer into the formal language of a compiler's internals. Regardless of what representation we choose for any part of this process, it's going to be subject to the article's quote: > This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.

No. There is a large difference between parsing commands which affect the structure of a program and directly parsing the structure itself. For one, commands that affect the structure in an invalid way can be rejected. Second, commands can be stored so that a history of source code manipulations can be replayed (which while possible via text ala git is very lossy and subject to merge issues - as stated in the article). In addition, commands are limited by context. So when parsing the user's input we now have a limited context to work within greatly improving accuracy and also simplifying the input space of the user. These are just a few of the reasons...

15

Benefits

4

Exampes of GUI elements / different visualizations than "code"

Math

Tables

Images, Colors, Numbers (a la KA CS)

4

Changesets

Joel is implying that using a structured editor would mean you get semantic changesets for free, which is not the case, but they're super cool

I like the wording **semantic changesets**

"language-aware patch theory" http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory

2

Editor integrations ++ partial parsing is hard

this is also a little less compelling reason, because lots of editors can handle this reasonably well

2

**misspellings** Avoiding user errors

misspellings (also something IntelliJ does just fine at catching & fixing)

2

**parser impl errors** Avoiding Implementation errors

when you have a parser that errors - also not something I think is super interesting / important

9

Downsides

3

giving up text. Advantages of text?

suuper adaptable

can express all kinds of things, and you only have to learn one editing paradigm / set of commands

5

giving up tools that expect & use text

vim

grep

diff

git diff

9

Joel - the expression problem & tables http://joelburget.com/the-expression-problem-and-tables/

2 ways you want something to be extensible: easily add new cases for a datatype, and easily add new functions over the datatype

2

OO makes it easy to add `columns` to the table, meaning new cases

but adding functions requires editing each column individually

2

Functional programming makes it easy to add `rows` to the table, meaning new functions over the datatype

but adding cases requires editing each row individually

So best(?) case would be to have everything together in a table, so that you can add either rows or columns at your fancy?

I mean, either way you're writing the contents of these methods; if you had a column visualization, then either OO or functional would be equally usable, right?

The expression problem is really a layout problem. It’s impossible to write a one-dimensional (plaintext) file such that data and actions are both immediate.

31

Why don't we have a general purpose tree editor https://pcmonk.wordpress.com/2014/04/01/why-dont-we-have-a-general-purpose-tree-editor/

wants a general platform for editing trees

29

From the comments

4

Treesheets http://strlen.com/treesheets/

"the ultimate replacement for spreadsheets, mind mappers, outliners, PIMs, text editors and small databases"

looks like a whiteboard where you can put rich spreadhsheets + trees

3

OneSlate https://oneslate.com/

http://demo.oneslate.com

an argument constructor - "support this argument w/"

2

Xiki! http://xiki.org

dunno if it's exactly the thing though

2

Ket https://sourceforge.net/projects/ket/ vim-inspired algebra editor?

Memofon http://web.archive.org/web/20141220180852/http://www.memofon.com/ markdown -> mindmaps

2

Fargo : http://fargo.io a pretty simplistic outliner?

http://littleoutliner.com/

GinkoApp! yay https://gingkoapp.com

4

Philsped - by philip c monk https://github.com/philipcmonk/phlisped

https://pcmonk.wordpress.com/2014/03/19/phlisped-an-experiment-in-graphical-programming/

https://pcmonk.wordpress.com/2014/03/20/a-short-demo-of-phlisped-the-graphical-programming-editor-experiment/

2

TinderBox http://www.eastgate.com/Tinderbox/ definitely should look at this for Notablemind

2

Huge list of outliners http://web.archive.org/web/20140404035349/http://www.editgrid.com/user/pplandry/List_of_Outliners

wow there are a crazy ton here

"ViewingDale" a mind mapper I guess

OmniOutliner for mac

Framemaker

Conglomerate (no releases for 10 years)

Thoughts about a general purpose tree editor http://web.archive.org/web/20160318063251/http://dmitra.com/graphiy/general-purpose-tree-editor/

10

semantic code highlighting https://visualstudiomagazine.com/articles/2014/08/01/semantic-code-highlighting.aspx

2

local variable colorization. assigns a semi-unique color to each variable in a local context

so you can see if two identifiers match up, and you can easily see where something is defined, etc.

2

more https://medium.com/@evnbr/coding-in-color-3a6db2743a1e#.r0vojavb4

sayin the same thing

https://github.com/equiet/recognizer

a vim plugin https://github.com/jaxbot/semantic-highlight.vim

atom plugin https://atom.io/packages/language-javascript-semantic

somebody against highlighting in general? http://www.linusakesson.net/programming/syntaxhighlighting/

a list of thing http://softwarerecs.stackexchange.com/a/17925

30

What's the deal w/ projectional editing? https://cloudalion.org/2016/05/29/whats-the-deal-with-projectional-editing/ 2016

9

2 ways to represent code:

1) a sequence of text characters

2) as a graph, w/ nodes connected by edges

:?!: "I like to think of writing new code as a process that starts with a graph that is embedded in our brain. Why a graph, you may ask? Because we think of things in terms of concepts and relations between these concepts"

If this is the situation, we make a few graph transformations in our head, transforming the high-level conceptual model of what we want to write into a more elaborate though simpler graph representing the code we actually want to write. Finally we convert this graph to text, and type this text on the keyboard.

Imagine you need to implement a function that calculates income tax one needs to pay based on income and expense data given to you as input. At the beginning, you think in term of expenses, deductibles, income tax, etc. This is known as the problem domain. Each of these is an individual concept, and there are connections between them. For example, income raises the tax due, but deductibles reduce it. The mental graph you start with is therefore a description of the problem domain, focused on the particular problem you need to solve. Then, in your mind, you convert this graph into another graph, where the concepts are those of your programming language. For example, you may convert income and expense data into structures stored in arrays, deductibles into Booleans, and tax calculations into arithmetic operations.

So, why does parsing complicate the design of programming languages? Mainly because it makes decisions made in the early stages of defining a language very critical as the language evolves.

However, this illuminates the problem with keywords: new versions of a programming language cannot add new keywords without breaking existing code!

Basically, every new syntax added to a language must be evaluated to see that it does not collide with some syntax that already exist. Although this looks trivial, the huge number of combinations of possible combinations of language constructs makes the task of extending the syntax of a language so very challenging.

2

What if we didn’t have to do this part? What if we could program using problem domain elements?

:t: umm so I think this is a faulty premise - we construct functions, types, etc, which mean that we can program using problem domain elements. We don't need to invent custom syntax for every domain object

2

"Projectional editing is therefore the closest you would probably get to transferring your mental graph directly into a graph on the computer."

yeah, again -> does custom syntax really win a lot more for us here than custom objects / types would?

11

## The editing part

some editing methods are common to most projectional editors.

2

Top-down editing: You select a placeholder (some empty space), type the beginning of the name of the concept you wish to place there, and select the concept you want from an auto-completion menu.

using a keyword, like `function`, and then it completes w/ the structure w/ holes

2

Bottom-up editing: Like top-down editing, just that you start with a space that is already occupied and select something to augment it. For example, you start with the number 1, and you select a plus (+) operator to get “1+_” (where _ is a placeholder for the right-hand operand).

some things

4

Special Actions: Some kinds of language concepts (or AST node-types) are associated with special commands or actions for editing. For example, a list can be associated with insertion and deletion operations. These actions can usually be selected from a menu, or can have keyboard shortcuts associated with them.

hmm what would these look like?

I think the basic operations of "move ast node" shoud be sufficient for a ton of things

paredit needs all the specials b/c there's no first-class idea of having an ast node selected. So slurp/barf are needed

Copy and Paste: Copy and paste operations can take entire sub-trees of the AST and copy them to another place in the AST. This is unlike textual copy and paste, which can copy arbitrary text and place it anywhere.

2

Projectional editing requires some getting used to. You can’t just type your code like you’re used to. You need to understand and respect the tree structure.

:!: goal: make sure you can pretty much type like you're used to

2

But none of these reasons are why projectional editing was invented. It was invented because it allows languages to evolve.

:t: hmmmm

https://www.youtube.com/user/brosenan/videos?sort=dd&view=0&shelf_id=0

23

Projectional Editing http://martinfowler.com/bliki/ProjectionalEditing.html 2005

3

Source editing http://martinfowler.com/bliki/SourceEditing.html

Definition

Source based programing environments hold the definition of a system in a set of source files which act as both an editable and storage representation of the system definition. These sources are then transformed to an executable representation that actually runs. Source based code is the most familiar form around today in contrast to in contrast to ProjectionalEditing (where I discuss the two in more detail).

7

Multiple representations of the system

editable representation: what you edit in order to change the system.

storage representation: the persistent record of the system definition.

executable representation: what is executed to make the system run - the executable.

abstract representation: used to manipulate and reason about system definition.

visualization representation: a non-editable view of the system definition.

:!: I'd add: mental representation, tends to have more context, connections, and annotations

2

:!: "With projectional editing the abstract representation is the is core definition of the system. "

money definition

A significant pragmatic problem with projectional editing is the fact that there is no generally accepted format for the storage representation.

5

Tools that would need to process a new format

editors

source control

difference vizualizers

... any others?

**configuration control system** (version control I think?)

21

An Editor for Composed Programs http://tratt.net/laurie/blog/entries/an_editor_for_composed_programs.html 2014

`Eco` project

"Syntax Directed Editing"

2

**parser errors / syntax** The problem" Rather it is that some apparently reasonable programs fail to parse, and the cause of the errors can be obscure, particularly to novice programmers.

:t: I think this is one problem that SDEs help with, but by no means the only one

10

Problems

2

First, programmers often get half way through an edit in one part of a file (e.g. starting an assignment expression) and realise they need to define something else earlier in a file. They therefore break off from the initial edit, often leaving the program in a syntactically invalid state, and make textual edits elsewhere, before returning to the initial edit. SDE tools tend to forbid such workflows since they need to keep the program in a syntactically valid state

:t: I think this should still be possible

3

If you ever done something like selecting 2 + 3 from the expression 2 + 3 * x, you have done just this. SDE tools force edits to be relative to a tree.

:t: when would you do this??

:t: ok, there are definitely things like this that we do, but only because we can occustomed our minds to thinking in this flat state. I think that editing would be *faster* and better in a purely structured world, even though some edits would be impossible

2

But, if I'm being honest, I wouldn't want to edit a program in MPS, using its current editor, and nor do I think programmers will take to it voluntarily: it makes too many simple things complicated.

ok, I really need to see MPS used

However, whilst MPS does a good job of hiding its SDE heritage when typing in new text, editing old text has many of the same restrictions as traditional SDE tools.

As far as I can tell, MPS has gradually special-cased some common operations to work normally (i.e. as in a text editor), but many common operations have surprising effects. In some cases, edits which are trivial in a traditional editor require special key-presses and actions in MPS to extract and reorder the tree.

2

we hoped to make an editor with all the tree goodness of SDE tools, but which would feel like a normal text editor

Eco https://github.com/softdevteam/eco

uses incremental parsing.

syntax errors are totally fine

:!: save format is a tree

70

kill sacred cows http://www.joshondesign.com/2012/04/09/open-letter-language-designers

3 list
{"id":"ooobspv5f9i6tw9vrq871ob8kp9f45l0","created":1480004346030,"modified":1480004346030,"collapsed":false,"content":"don't store code as ASCII on disk. do something more interesting than that","type":"list"}

save the structure

store useful metadata, non-code and non-text resources

list
{"id":"04x07r1az4qogi9rjx2iwd9n2qgyzhrv","created":1480004383449,"modified":1480004383449,"collapsed":true,"content":"\"A plain text editor is just an IDE with no useful features\" :D ","type":"list"}
7 list
{"id":"5om6u6dx1ueodrh82h8p7qm56ndfmbht","created":1480004510467,"modified":1480004510467,"collapsed":false,"content":"don't think \"less syntax is good\"","type":"list"}

Minimal syntax isn't the answer. The more specific the programmer can be the better.

Minimal syntax is seductive because we like the idea of being concise and typing nothing extra. This is all very well and good.

But the solution isn't to remove syntax, but rather make it optional.

If the compiler can figure out what the programmer means without extra parenthesis and semicolons, then great, but let us add it back in if we want clarity.

2

Make typing our variables optional for when we are hacking, but let us be more strict when we get to production.

:t: I want to show inferred types everywhere, and have a visual distinction between "locked down" types nad "loose" types -- types that I've said should be enforced, and types that are just indicating what the inference engine has decided. Then you can click on a type to lock it down, or lock it to something more restrictive than the inferred type

list
{"id":"25spib0dk4sfyrvsw6pj2teaxs7uxmwp","created":1480004712902,"modified":1480004712902,"collapsed":true,"content":"tabs vs spaces is ridiculous","type":"list"}
5 list
{"id":"hd90r9xpwtq9exzwr2wh36ywv97a1qrf","created":1480004721872,"modified":1480004721872,"collapsed":false,"content":"there are plenty of good type systems. here's what the world needs","type":"list"}

good modules

2

escape from "classpath hell"

the ability to add a new module and *know* it will work without modification & without breaking something else

fix versioning

2 list
{"id":"ys0gmo2u7dblt7zmu0o2wonzyqfpdmo3","created":1480004797013,"modified":1480004797013,"collapsed":false,"content":"let programmers extend the syntax (e.g. macros)","type":"list"}

:t: what do macros look like in a structured editor? idk!

list
{"id":"x047vmfiynhi3va0zgq7i8u3mb5n39h3","created":1480004798885,"modified":1480004798885,"collapsed":true,"content":"do garbage collection","type":"list"}
list
{"id":"hxqpdo2876a4ior286m5dblxk00035z2","created":1480004838371,"modified":1480004838371,"collapsed":true,"content":"","type":"list"}
42

Part 2 http://www.joshondesign.com/2012/04/14/sacred-cows-2

Most people got hung up on my first point: don't store source code as plain text on disk. I thought it was innovative but relatively uncontroversial. Surely, one day we won't store source as ASCII text files, so let's start thinking about it now

11

The Source Code as ASCII think

5

ecosystem of tools around code as text

version control

CI / CD (I don't think this would actually be effected?)

diff tools

IDEs

5

What is a codebase?

a large graph structure

potentially circular

non-code resources (images)

semi-code (XML)

Source code is a lossy representation of the codebase

3

**nested block comments** Argument: nested block comments

Ocaml has this just fine....

so this is not a compelling case for "we need a structured editor"

8

Examples that become trivial with a graph system

Version Control can do much better (no, not perfect) diffs

Could visualize & display semantic changes in a changelog, much easier to read & understand

Renaming & refactoring is triviial ( ooh, having scripts be able to trivially do codemods is super enticing)

Multiline strings ( :-1: ok, no points for this one - javascript does this fine)

2

Variable interpolation ( :-1: also no points. see javascript)

kindof partial points for "no need for escaping rules", but not really because who ever things "oh if only string escaping weren't so cumbersome". It's fine

No need to worry about delimiters like `{}` and `()` ( :-1: also solving something that's not a problem.)

17

New things that become possible

better interface for defining RegExps :+1: this would be awesome

inline docs w/ a rich text editor :+1: sure, although structured editing is not strictly required for this (see moonshine, Eco)

2

**metadata** add metadata to functions n stuff (we already have this a little bit with `@Annotation`s, but I think the idea here is that the annotation would then duplicate the display of the function code in the documentation. Which sounds awesome :| kindof

basically, there are a lot of things that fall out of rendering the code richly & purposefully, instead of thinking that we have to stick to some ~static plain-text representation

3

**inline unit tests** Inline unit tests :-1: no points

I mean yes that's cool, but have you seen intellij/xcode? This is not a structured editor thing

"I can create a new test for the current code without creating new classes and files" this also has ~little to do with structured editing. Why is adding files bad? If it's automatic & you don't notice, then it's fine.

8

**non-code resources inline** Edit & store non-code resources inline :| also a half-point on this one

icons

vector artwork

animation interpolators

hex values for colors

this would all be stored as part of the source & edited inline using the appropriate interface

this doesn't really need a structured editor - there are plugins for atom / brackets that will show images inline (intellij and xcode will do this for you in the gutter), and we have hex values rendered as color swatches in a bunch of different editors / plugins.

*but* the ability to store these images as part of the "code" file is a cool idea, although not too cool. Beacuse if you have a standard place to put the image (e.g. Xcode w/ Assets, or IntelliJ with the `res` directory, this benefit isn't really much of a step up. Yes it'll make tooling easier (you don't have to know the magic directory to look in, etc.)

Visually arranging code in new & interesting ways

TODO read the rest of this blog

4

HN https://news.ycombinator.com/item?id=3816953

3

"I should *not* be required to run in a window system"

hmmm this is not something I super care about supporting...

hotfixing on a production server doesn't have to be done in the new age of containers, etc.

disqus comments https://disqus.com/home/discussion/joshondesign/sacred_language_cows_part_2_we_can_rebuild_it_we_have_the_technology/

28

sacred cows 2 -- forum discussion from pdxfunc https://groups.google.com/d/topic/pdxfunc/mypE35ohfWg/discussion

9

Problems with non-ASCII representation

6

For example, turns out that non-ASCII representations are fragile--go figure. Change the language representation slightly, and everything else changes a lot. There's no limping along patching things by hand until the tools catch up, either. All the tools have to change with the representation: flag day. And the tools have to accept old representations, because the representations are hard to upgrade: backward compatibility hell.

5

:t: hmmm. so what tools would we have, and would they be general enough to accomodate new languages w/o configuration, and have reasonable fallback if we change the language AST structure?

git diff -> yes, I think we could just have a generic tree diffing algorithm, and more "intelligent" algorithms that would be lagnuage aware. But tree diffing would be a good fallback

IDEs - hopefully could be defined generally (w/ the grammar etc) that they could respond to changes in syntax? Or fall back to a generalized tree editor if the code is in a new version of the language that it doesn't support yet?

2

we have this currently with syntax highlighting -- new js syntax comes out, and the editors highlight all wrong, but it doesn't impede coding much because highlighting is just icing. If we have a structured editor that is unable to handle the structure, then bad things.

:!: so we need to make sure that "releasing a new version of the language won't cause mass breakage in IDEs"

2

Another dirty secret was that the magic internal representation didn't turn out to be necessary. Modern PL implementations can lex, parse and structure tens or even hundreds of thousands of ASCII lines per second. If you want some "special" program representation for a tool, you can just go parse everything into it, do your business, and get out. Take a look at the Inform 7 compiler: Whole-program translation of syntactically wacky ASCII text every time you want to run your game. Happens so fast you don't even notice until the games get really, really, really big. Look at Sparse, and how fast it can do whole-program analysis of the Linux kernel. Etc.

:t: so "you don't really need it", based on the idea that the main draw is saving parse time. I can do better

2

It may have had the structure available to tools making for famously great refactoring, etc, but the user's experience of editing the code was still textual

:!: great rebuttal :D

6

The Model (generalized format)

each node has a GUID + multiset of edges

schema DSL - define an interesting structure in the graph :?: I dont understand this

projection DSL - describe how a specific graph should be displayed and edited

general projections that could display any graph (text-like, bubble+line, etc) if a language-specific DSL is unavailable

a type checking DSL

:?: hmmm I don't really understand what he means here

extending a structured language is massively easier than a text one

"I wouldn't hate using a system that is totally structured but stores the data back in a source format

2

Questions for the standardized graph format

So there are a number of formats that do what you are describing, with all sorts of differing semantics. Some questions that arise, and which your simple-and-general format will need to address: * Can nodes be labeled, in addition to their identity? * Are there different types of nodes? * If so, can nodes have more than one type? * Can edges be labeled? * Do edges have identity? * Are there different types of edges? * Are edges directed? * Can an edge's head be the same as its tail? * Must edges only link nodes, or can they link edges? * Can an edge start/end at itself? * Must the graph be connected? * Can there be redundant edges? * If things have types, are types represented in the graph, or external to it? * What are the semantics of the labels? Are they text, typed data, etc.? * Can nodes be used to label things? * Can edges be used to label things? * Can subgraphs be used to label things? * Can subgraphs be used as nodes? * Can nodes have content? * Can nodes contain subgraphs? * If nodes can contain other parts of the graph, are there nesting rules? If so, how are they enforced? * What sort of operations are supported on the graphs? * Assuming that there are operations to visit all nodes/edges, are they stable (e.g. does adding/removing a node cause the order in which other nodes are visited to change)? * Does the storage format cache information about the graph to optimize common operations (and is this information saved?) * Are concurrent operations supported? * Can graphs be merged, unified, extracted, etc.?

5

Answers on standardized graph format (from jake brownson, not joshondesign)

Nodes w/ identity

Edges w/ start + end at nodes

But maybe edges also have identities...

all semantic meaning is at the "next level" of the graph structure

3

Typographic http://joshondesign.com/2014/08/22/typopl

4

Storing code in the DB https://www.infoq.com/news/2008/06/storing-code-in-db

If you can treat the reflected code from a programming language like an abstract data structure, why can’t you just keep the source itself in a similarly abstracted data structure? Isn’t the structure of a program more similar to a graph, than a list?

2

**against:** Things like the number of spaces between operators can be used for nice stuff like laying out bits of consecutive lines that have parallel meaning so that they line up. Ordering of functions can be chosen so as to tell a narrative. People have grown quite creative in using the tools they have to write expressive code. If you're going to take this away, I expect to see a good reason to believe that it can be replaced by something equally effective.

:t: this feels to me more like a "this is the best we've got so we make do" rather than "this is a really important thing. Yes, maybe people have gotten creative, but that doesn't mean it's not a square peg in a round hole.

42

Eidola http://web.archive.org/web/20110222150340/http://eidola.org/about.shtml

We rarely use code to explain code -- ask a programmer to explain their code, and you'll probably get a diagram with some boxes and arrows. The powerful ideas of high-level languages suffer because we have to work with them through a low-level notation system.

Textual source code is an anachronism, and although modern computers are hardly dumb terminals, we still design programming languages as if they were.

5

they all suffer from at least some of the following problems:

**Shadowing a more definitive but inherently less structured representation**. Modeling tools attempt to represent a program nicely before it becomes source code; code browsers attempt this after. However, both are always out of sync by a compile cycle or even a design cycle, and always either end up playing catch-up to the changing source code, or smattering it with "GENERATED CODE -- DO NOT EDIT." The basic problem here is that the canonical form of a program is still the source code.

**Poor representation of information**

**Awkward user interfaces**. Code browser interfaces tend to look to standard widget sets for representing programs, with the result that they not only display structure poorly, but make changing it extremely awkward. A good system should make coding easier and faster than plain text -- even giving the option of using text where that makes good sense.

**Limited language domains**. Most modeling tools and code browsers represent only a subset of the target language, making the graphical system at best a useful supplement to the text. Component-based systems like Java Beans can be more purely graphical and quite wonderful, but are not robust enough to replace languages as we know them now. A component's job is to abstract away all of the complex structure of a full-scale programming language to create very simple pieces a user can connect in very simple ways. This is fine and accomplishes truly wonderful things, but the components still rely on a more robust language as a foundation.

The basic principles of Eidola are as follows:

1. The language's foundation is a clean, representation-independent formal semantics. 2. The structures of the formal semantics are the fundamental form of programs. 3. A layer of user interfaces form a notation system for these semantic structures.

Eidola, on the other hand, starts and ends in the realm of mathematical structure, and these structures are independent of representation. From a traditional point of view, in Eidola the programmer is directly manipulating the parse tree, but a better way to think of it is that an Eidola program's fundamental form is structured in way that makes the distinction between source code and parse tree meaningless.

Eidola's basic view of the world is a type-centric object-oriented model, backed by a formal semantics.

This means that there is no single "true" binary form of an Eidola program; the canonical form is mathematical. Every memory representation or storage form satisfying the semantics is an equally legitimate form of a program.

The kernel allows different interfaces to observe, query, and modify semantic structures. The kernel's responsibility is to manage the structure of a program; the interfaces' responsibility is to represent this information well and make it easy to change and work with. Different interfaces can observe the same element of a program; if one modifies it, all reflect the change immediately through an event mechanism. Thus, Eidola has no single correct or fundamental notation, and a programmer can view the same program through the lens of different representations for different kinds of insight.

:!: I really like these principles

2

FAQ http://web.archive.org/web/20060924052726/http://eidola.org/faq.shtml

2

Possible Eidola notations http://web.archive.org/web/20060924053251/http://eidola.org/notation/gallery/eidola/

lots of cool ideas here

23

Good Old Source Code http://web.archive.org/web/20060924053133/http://eidola.org/notation/gallery/programs/sourcecode.shtml

6

objections to source code

it presents many features of program structure poorly, particularly large-scale strcuture

it unnecessarily ties th efundamental design of the language to its human presentation

it privileges on form of a program over all others (and this form is hard to work with the semantic structure)

transaltion messes for alternative visual presentations and storage formats

very high barrier to entry for creating sophisticated new developer tools

16

Why we use source code

2

the technology factor

textual source code became tightly intertwined with programming language design

5

the language factor

the concept of human and computer languages are intertwined

source files have a sequential structure, even when the structure has no meaning (e.g. order of members in a class)

2

fundamental difference: computer languages have a meaning which is separable from the language, and human languages do not

:t: or at least, computer languages have a well-defined and *cleanly representable* independent of

8

tools factor

2

Since the structure of the data doesn't reflect the semantics of the code, tools that manipulate source code can cheerfully ignore any levels of abstraction irrelevant to their task

:!: this is really well put. How can I reproduce that? in a graph format that accomodates traditional tools & stuff

it's easy to write programs that manipulate text

people can paste in pseudocode, or code from another language, and incrementally transform it

:!: oooh this will be an important thing to maintain.

TODO allow pasting in blocks of whatever and treating it as e.g. a comment (can do anywhere a statement can go)

Eidola should, in priciple, be at least as convenient and easy to use as a textual programming language

2

The next revolution http://netundocumented.com/blog/2004/06/whidbey-may-miss-the-next-coding-revolution

lots of the stuff mentioned is totally done in the modern IDE, without relying on structured editing

52

SCID http://web.archive.org/web/20070621162318/http://mindprod.com/projects/scid.html

creating source code in linear text files do the equivalent of keeping their accounting books using a CPM Wordstar text editor. We would never dream of handing a customer such error prone tools for manipulating such complicated cross-linked data as source code. If a customer had such data, we would offer a GUI-based data entry system with all sorts of point and click features, extreme data validation, and ability to reuse that data, view it in many ways, and search it by any key.

43

Cool ideas

4

"Show me a switch statement **as if** it had been handled with a set of subclasses"

this is a fascinating idea.

e.g. instead of `switch (exp) { case _: case _: case _ }`, you just see `someclass.callAMethod()`?

seems like this would be a lot easier to do in the other direction. Switch cases are more general, and won't always translate cleanly back

5

"you no longer have to decide whether to bundle all your layout code together or to bundle it with the corresponding button instantiation"

:i: ooohhh so this sounds like method expansion? Whe you can say "expand this method to show me the contents in its place"

but this idea is also "see all the code concerning the save button"

so this is like my idea of figuring out all the uses of an observable

"show me the code, in rough execution order, that deals with this variable"

"hide all calls to X package"

show logic as if it were written in a decision table

Warnier-Orr diagram, UML or sequence diagram

show me a flow chart of ifs, loops, etc

table view of an enum declaration

table view of an enum declaration

jump to definition

show usages

show mutations of a vbl

collapse function bodies, comments

autocomplete w/ method signature

2

optionally include method names in invocations, e.g `drawCircle( /* x */ point.x, /* y */ point.y, /* radius */ 5)`

:!: yeah! So you can have swift/objc-style verbosity if you want

global rename refactor

show me the program with spanish strings instead (i18n). Highlight places where the spanish string is missing

list local variables / classes that are in scope

optional semicolon display

Hoogle-ish "I want this type, given the local variables, what can you do for me"

inline pre/post conditions that can be shown/hidden, and extracted for testing

track debug logging so you can click the log statement & jump to the place it was called (js console does this)

display code colored by age (newer code pink or sth) - you can know age at much finer resolution than just `git blame` level

display declarations in a grid, w/ `type | name | initialization`

"show me a pseudocode version"

2

variabled-sized parenthesis

display digits grouped by three `1 000 000 000`

mark bounds of if/loops

2

show a version of the function under some statically-analyzable circumstances. e.g. "show me only the code that executed when this flag is `true`"

see Kent's "slice-js" http://slides.com/kentcdodds/faster-javascript#/

editor-layer macros - fill out a form, or just call something that looks like a function (only with literals probably) and it will gen the code

You want to be able to trace not only program flow but data flow. Consider a program rendered like a flow chart, with parts of it suppressed. Lines show how a particular datum flows through the system, how it gets operated on and modified. Code that is not germane to that flow is temporarily suppressed

let you refactor a method by breaking it into smaller ones. It should be able to automatically determine parameters & their types.

make codemods super easy to do

7

Ideas for different displays

Make the beginnings of methods more visually obvious. The plain Java syntax tends to camouflage them. Ditto for temporary variable declarations. Hide comments. Show just loop structure. Show just code involved with class X. Hide all code that involves calls to the java.awt package Highlight all code that does bit shifting or division. Highlight all uses of the sin method, but only in class Moses, not Math. Gray out all code that deals with error handling. All that is left is the normal case. Colour code so that the darker the shade, the more frequently it is executed. Show me a switch statement as if it had been handled with a set of subclasses. There is underlying deep structure here. I should be able to view the code as if it had been done with switch or as if it had been done with polymorphism. Sometimes you are interested in all the facts about Dalmatians. Sometimes you are interested in comparing all the different ways different breeds of dogs bury their bones. Why should you have to pre-decide on a representation that lets you see only one point of view? Sometimes you want to see all the code concerning the save button. Other times you want to see only code involving hooking up listeners for all buttons/menu items. Other times you are interested only in code that affects layout. The SCID can hide non relevant code. It can also dynamically reorder code for the current purpose. You no longer have to decide whether to bundle all your layout code together or to bundle it with the corresponding button instantiation. You can have it both ways! Show me a set of subclasses as if the code had been handled by a giant switch. This lets me compare the equivalent code in all subclasses. Similarly let me compare just two subclasses. This is like a DIFF utility that notices the differences between two methods and generates a single program that handles both, taking advantage of commonalities. Show me the logic as if it had been written with a PET decision table. Here you have a list of conditions, then a list of actions. The SCID can ensure that all possible combinations are covered, and you easily proofread the logic originally coded in traditional nested if logic. You can write a decision table and have the SCID convert it to nested if logic or a giant switch indexed by concatenated binary condition representations. Here is a simple example:

Let me switch rapidly back and forth between different representations of my code

Show me the definition of this variable or method just by clicking it. Tell me which classes and methods call this method and how many times. This XREF is always up to date because the source is in a database. It does not need to be scanned periodically to create a fresh XREF. Optionally show me code with all class names fully qualified by package, or remove that qualification for all or some classes. Tell me which classes and methods look at this variable and how many times. Similarly, tell me which ones change it. Collapse/expand level of detail. e.g. collapse detail of CASE bodies, LOOP bodies, IF/ELSE bodies, parameter details leaving just the names of the methods being called, collapse purely arithmetic assignments. By using specially coded comments you can hide/reveal various classes of them. You can hide code and just read comments, or perhaps just see the overview comments, or just the comments explaining what the various classes are for etc. The key is to show you just the level of detail in comments you need for the current task without being overwhelmed with irrelevant detail. You could configure which categories of comments you wanted to see fully expanded, and which you wanted revealed only by hoverhelp, and which you wanted totally suppressed. By using hoverhelp to display comments you free up screen real estate to see more code at once on screen. You could implement comment hiding/hoverhelp without a scid using a smart traditional text editor using:

When I write the code to call a method, show me the names, types and Javadoc for the parameters. Show me the names of the parameters next to the parameters themselves in each method invocation so I can proof-read it, the way you can in Ada-95:

Show me the definition of this variable or method just by clicking it. Tell me which classes and methods call this method and how many times. This XREF is always up to date because the source is in a database. It does not need to be scanned periodically to create a fresh XREF. Optionally show me code with all class names fully qualified by package, or remove that qualification for all or some classes. Tell me which classes and methods look at this variable and how many times. Similarly, tell me which ones change it. Collapse/expand level of detail. e.g. collapse detail of CASE bodies, LOOP bodies, IF/ELSE bodies, parameter details leaving just the names of the methods being called, collapse purely arithmetic assignments. By using specially coded comments you can hide/reveal various classes of them. You can hide code and just read comments, or perhaps just see the overview comments, or just the comments explaining what the various classes are for etc. The key is to show you just the level of detail in comments you need for the current task without being overwhelmed with irrelevant detail. You could configure which categories of comments you wanted to see fully expanded, and which you wanted revealed only by hoverhelp, and which you wanted totally suppressed. By using hoverhelp to display comments you free up screen real estate to see more code at once on screen. You could implement comment hiding/hoverhelp without a scid using a smart traditional text editor using: /* [1!] */ markers to tag comments with level of detail and importance (or severity as Chuck Sheehan, the technique's inventor, calls it.) /* 1=overview .. 9=detail !=important */ Programmers very familiar with the code might be less likely to remove Javadoc or complain about it, if they could get it off their screens. The main drawback of doing this is out of sight, out of mind. Cowboy coders would be even less likely to keep comments in sync with the code. When I write the code to call a method, show me the names, types and Javadoc for the parameters. Show me the names of the parameters next to the parameters themselves in each method invocation so I can proof-read it, the way you can in Ada-95: drawCircle( x => point.x, y => point.y, radius => 5 ); or Modula-3: drawCircle( x := point.x, y := point.y, radius := 5 ); or as Java-style comments: drawCircle( /* x */ point.x, /* y */ point.y, /* radius */ 5 ); As I become familiar with certain methods, turn this expansion off for those methods only. In a similar way, optionally expand/collapse calls with parameter type information as well. When I type in an identifier the scid has never heard off, use spell check logic to suggest what I likely meant. Eclipse now does this. I spend so much time correcting typos, variant abbreviations, errors in capitalisation, inconsintent capitalisation e.g. Hashtable vs HashTable when several variants are plausible. Warn me if I reuse a name locally that is already defined as an instance or static variable, except for the usual exceptions. Show me my declarations aligned in columns, perhaps using compact glyphs to indicate static, instance, public etc. so that I can easily pick out parallels in names and types. Let me see switch statements as if they had been coded in Eiffel as inspect statements. Let me see declarations, expressions, loops, if nests etc, in my favourite syntax, in any of the Algol family of languages such as: Eiffel, Ada-95, Java, Dylan, Scheme, Algol-68, beta, Pascal, Delphi, Oberon, Modula, NetRexx, Python, Sather, roll-your-own such as Abundance or even as flowcharts. You should be able to key code in any of these modes too. The language would still be Java underneath, with a surface veneer to simulate the coding conventions of these other languages. Show me the Javadoc comment for that parameter on demand. Global method renaming. Accurate, unambiguous method and variable naming is the most underrated technique for writing maintainable code. Whenever you add a new method, there is a strong possibility some existing similar method should be renamed so the distiction between the two is more clear. Scope name clashes can be resolved to avoid confusing programmers. Compilers have no trouble with accidentally duplicated names, but programmers are easily befuddled. Globally renaming manually is so error-prone that it is almost never done manually. With a SCID, it would be effortless and completed in an eye blink. You could also do generalisations of renaming, e.g. reordering parameters to some more consistent standard, or adding overloaded methods to handle common default parameters, and having all code converted to use the new overloaded methods. Show me the program with the Spanish strings inserted. Show it to me with the Spanish variable names where they are available, but use English ones where not. Let me read it as if it were written purely for Spanish with any internationalisation bubblegum housekeeping hidden. Show me the program with all needless () levels removed that our newbie programmer put in. The () are not actually stored in the database. They are regenerated to suit the individual programmer preference. Show me the program with extra parentheses () inserted because I can never remember the precedence distinctions between && and <. Show me the program with the Whazmotron custom glyph set so that I can easily pick out if begin end, loop begin end, class begin end, method begin end. What classes are available to me at this point in the program? What local variables are in scope? How should you display semicolons? Once you have the parse tree, they are purely for the convenience of the humans reading the code. They are not actually in the computer's parse tree. You could display with any statement convention you wanted. Every programmer could flip between any display mode they wanted. you might leave them out. You might use Pascal separator, Java-like terminator, or Eiffel-like only-when-it-would-otherwise-be-confusing rules. You might use a pure indenting convention. You might draw boxes, or non-outlined boxes around each statement in a subtly different shade from the background colour. You might use a special fat glyph, perhaps a little red stop sign. that is very easy to tell apart from a colon. You should be able to ask, what methods are available at this point in the program that produce a Zomblat object? What methods are available that take a Zomblat object as a parameter? What methods are available that take both a Zomblat and a Color object? What methods are available anywhere that produce a Zomblat object? What methods are available that take a Zomblat object as a parameter? Show/hide the Eiffelian pre/post assertions. You can fill in dialog boxes about each parameter, variable or return results. For ints you may specify the acceptable low-high bounds. For strings you would specify whether they may be, null, empty "" and whether they may have lead/trail blanks. You might specify that they must be all upper case, all numeric, all lower case, no accented letters etc. For enumerations you would specify the list of allowable values. For debugging, you can turn this code on to ensure all the conditions are being met. When debugging, the SCID secretly captures information about where in the code each string in the output came from so that you can click anying in the console output and instally jump to the System.out. println statement that generated it. It should be easy, when debugging, to temporarily assign colours to the console output from different classes or println statements to help classify them similar to the way logging can be configured. Capture additional information about fields useful for data entry, such as low-high bounds, blank if zero, left leading zero fill, commas, lists of legal values, justification, natural layout parameters, field name or display, prompts, field widths, validation routines,… Programs can access this data rather than specifying it inline in the code. This keeps everything about the variable in one place where it can be easily accessed and changed. It also facilitates searching for fields that share some property and bulk replacing it. That was an ambiguous name for that method. Change it everywhere it is used to this clearer name, but don't change it where that same name is used in another class. Computer, be clever, don't pester me to figure it out for you which ones should be changed. IBM's Visual Age can do this already. With a database, a variable or method name string actually appears in only one place, (everywhere else the name is represented by a pointer to that name), so it is trivial to make a global change. Display the program using foreground/background color, font family, font size, font style (bold, italic), lines, glyphs and icons to pack as much additional information on the screen as possible. For example you might be able to tell a stack/temporary variable, from an instance variable from a static variable from a constant just by looking the font, or some slight shade of foreground or background colour difference, e.g. dark brown, orangey/brown, and light brown foreground. The clues may be almost subliminal. You could encode all kinds of information compactly such as: local, parameter, instance, static, my class, Sun class, type, package, class, definition, keyword, final… all in a way that did not get in your face. You could encode for whatever distinctions were important at the time. Variable pitch fonts are possible without giving up alignment. They put more on the screen and are more readable than fix pitch fonts. Exactly how these abilities are used will change constantly depending on your current task. The idea is to encode information about symbols in their look. You could use the full colour abilities of the modern screen to give subliminal clues, e.g. by automatically assigning a portion of the spectrum to each package/class using a pastel shades as the backgrounds to any references to methods or variables of that class. You could bold face the definition of any identifier to make it stand out. You could make calls to Sun code look different from calls to you own code. Chris Uppal suggested using colour coding by author. He noted that in every shop where he had worked, there were programmers he could trust and ones he did not. If he were attempting to understand or debug a chunk of code it would help if he knew which stretches could be trusted to do what they claimed to do, and which stretches warranted more scrutiny. You could encode the age of code by colour. Generally the newest code is most suspect if there is a problem. Sometimes old code, that was done before some specification change occurred, needs to be examined and ticked off as compatible with the new spec. You can use colour to help keep track of which code has been checked. A scid would know the age of every token to the millisecond, much finer resolution that could be pulled off with CVS deltas. You could ask that all code be filtered out unless it had to do with instantiating objects (other than common ones like String). This skeleton view would give you a pretty good overview of how all the classes fit together. You could ask to globally visit all references to a given method or variable, and tick them off once each was dealt with. You could do quite a bit of code writing by point and click. There is no need to type a variable or method name, just select it from a palette of likely variable or method names. You could type personal abbreviations for them and have them expanded. You could view code with your personal names or the official ones. For example to write a FOR loop there might be boxes you fill in for the various intializer, terminator, and incrementor expression. They would default to int i=0, i

Display using lines or slight shade variations in background colour to mark the bounds of ifs and loops. Programs would look more like flow charts, or more like text with highlights, as the programmer preferred for the current purpose. Vertical striation watermarks in the background would make it easier to see matching alignments. You might draw thin vari-shaded boxes around each nested block. You might bracket blocks with {} turned 90 degrees and made 4 inches wide. CSD is one such representation. Optionally apply Hungarian notation warts to variable names to indicate variable type or scope. Turn them on and off at will. They are always accurate. E.g. Scope prefixes might work like this: local a (e.g. aPoint) param p (e.g. pPoint) member instance m (e.g. mPoint) static s (e.g. sPoint) exception X (e.g. XOutOfBounds) Highlight all code involving floating point. What I am talking about here is not permanently highlighting floating point operators and operands, or example, but just for the next 10 minutes, because floating point is the thing I am concentrating on at the moment. The syntax colouring schemes I am familiar with are designed to be done once and left alone once you have them tweaked the way you like them. For a SCID, you need not only ways to change the syntax highlighting, but to rapidly flip between presets to enhance the current interest and to suppress the current irrelevancies. You also need ways to rapidly set up new interest constellations. I use the word highlight in a broader sense. With a GUI and SCID you may use combinations of colour, font, size, glyphs, background colour, hiding, folding, lines, geometric shapes, bold, italic, blink etc. etc. to make a certain constellation of currently interesting features leap out at you. Different interesting features would use different highlighting techniques to grab your attention simultaneously. If you elected to view an IF as a flow chart, you could more easily compare the true and false branches line by line side by side. With the modern GUI's ability to rapidly pan in 2D or even 3D, we should break the mindset that programs have to be a single linear column of text. We can pay more attention to what actually works for the eye, not what is easiest to code. I am pretty sure than long horizontal lines of text, stretching all the way across the screen, so popular now, will prove to be suboptimal. You might look for inspiration to website navigation aids or the Windows ME exploding menus. You might create your own glyphs or icons to represent methods, classes, operators, variables, syntatic elements etc. That way you can pack more information onto the screen at once. You create a personal way of displaying the program to yourself that no one else in the universe need be able to make sense of. You share the underlying code syntax tree with your fellow programmers. The representation is personal and evanescent. You want to see program flow under a certain set of circumstances. Code that would not be executed when those circumstances don't apply is temporarily suppressed from the display. You are left with a simplified flow chart that shows execution flow. You can focus on the usual case, then later view various pathological cases, independently. You don't have to deal with the full complexity of everything all the time the way you do in conventional coding. The whole point of the SCID is to temporarily suppress what is temporarily irrelevant. Idiom expansion. There are many things in Java that take reams of code to express. You can't abbreviate it by writing a method. Instead, you code an abbreviation, or fill in some blanks in a dialog box, and it generates the bubblegum for you, error-free. Idiom detection. Java is verbose, but tends to follows standard patterns called idioms, e.g. enumerating a set, hooking up buttons to listen for events. The SCID can detect the pattern and replace it with an abbreviation for display. If code refuses to abbreviate, but that looks like an idiom, you can be sure is not quite the standard idiom. That may be an error, or it may be deliberate deliberate. Code is much easier to proof read this way. You don't need your eyes to detect tiny variations from the standard idioms. You want to be able to trace not only program flow but data flow. Consider a program rendered like a flow chart, with parts of it suppressed. Lines show how a particular datum flows through the system, how it gets operated on and modified. Code that is not germane to that flow is temporarily suppressed. I am hand waving frantically here. What the heck am I talking about? Consider a program where you entered a birthdate. There are parts of the program that would be totally unaffected by that birthdate. Those parts could be suppressed if you were concerned with how the birthdate affects the program. There are degrees of association. A test on birthdate is a little less associated than some code that transforms a birthdate ordinal into year, month and day for display. Pale finals. I would like the SCID to mark all variables that are not redefined with a pale final to let me know I need not worry about subsequent redefinitions of the value. Similarly, I would like the SCID to maark all methods and classes that are not overridden with a pale final to let me know there are no redefinitions of the method to worry about. These would be generated dynamically, not part of the source code, and could be turned on or off. They would look like regular finals, except would be displayed in a pale colour to indicate their ghostly nature. They would not prevent me from redefining the variable or the method. The pale final would simply disappear. Display complicated expressions in true mathematical form much as TEX or the Microsoft equation editor would display them, with variable sized parentheses and denominators under numerators. To help understand expressions, you could ask bits of them to collapse on screen. A simple version would adjust the amount of space around each operator to indicate relative precedence. Low precedence operators would be surrounded by more space. Java has 13 levels of precedence, but you would not normally find them all in one expression. The relative distinctions in spacing could be obvious. You would not have a fixed amount of space for each precedence level. You could also display complex expressions as a parse tree, with operators at the nodes. What you see need not have that much relation to what you type. For example, you could type GT for > since for some people it is easier to type. Let you refactor code by breaking up methods into smaller ones. You just highlight the hunk of inline code you want made into a separate method. In theory it should even be possible to automatically determine the parameters and their types. The system could then go looking for code that does inline what your new methods do, and replace that inline code with the new encapsulated calls. Lets you select colours within the SCID using a ColorChooser. Colours and variables/constants representing colours in code can be represented any combination of three ways: By colour sample swatch. By colour name. By colour number (hex/decimal) Exploit new high res 1 meter square LCD or gas plasma panels so you have room to see everything at once, visually navigating your way around the entire code space, rather than peeking at it through a toilet tube the way we do now. With everything preparsed, writing your own custom code conversions would be a lot easier. For example, you might write a translator from AWT to Swing code. True visual editing. Your GUI program looks like the final screen output. You right click on any component which brings up a dialog box from which you can change, colour, font, border, initialisation, associated event handlers… mostly by ticking off boxes and making muliple choice selections. Your program always works to some degree since you can't select anything syntactically invalid. Navigation is far easier, since you don't even need to remember the names of things. You can of course find out the names of things by right clicking them. Code becomes far less procedural and more OO. A supermarket parking lot helps its customers find their cars by posting signs with animals on them in various parts of the parking lot. It is much easier for someone to remember they left their car near the salmon than in sector E6. Similarly you could embed landmark symbols in the code, perhaps with purely personal meaning, and only visible to one programmer, just to help her find her way around. You could click on the salmonto get back to a section of code you were working on recently. For importing ordinary Java source code, a parser such as JavaCC or ANTLR might be useful. See parser in the Java & Internet Glossary. Ability to add shortcuts to the syntax such as Abundance-style moods and for-each loops. Instead of saying x.keyin(); y.keyin(); z.keyin(); you can declare keyin as a mood, and say: keyin x, y, z; You could say things like: for ( MyArray) { MyArray.x += MyArray.y + 1; } to run through all the elements of the array and provide an implied default subscript inside the loop body. Collection iteration could be much terser as it is in most modern languages. You can invent your own language shortcuts. No other programmer need view them. They would see perfectly standard Java. However, when you viewed their code, your shortcuts would be applied so you would not have wade through their reams of dinosaurian repetition. You might for example add case ranges to the switch, implemented with a binary search. If your shortcut got in the way, you could drop it, and instantly see standard Java again. After all, this is software, right? It is supposed to be malleable and comfortable. With traditional coding techniques software becomes so rigid. It is harder to change that the supposed hardware. I suspect that SCIDs will create a revolution in terseness of language design. It will come about gradually like this. A SCID will give you the ability to temporarily hide bookkeeping/busywork/plumbing/wiring (pick your analogy) details. Next will come the call for the SCID to automatically generate those details. Next will come the complete suppression of them from the application programmer's awareness. They will be hidden completely behind the walls, no longer part of the day-to-day application programming language. Every time you can suppress 30% of the busywork, a whole new set of patterns emerge that were formerly obscured by all that fussy detail. Suddenly, you discover new ways to more tersely specify your desires to the computer. You see new levels of bookkeeping/busywork/plumbing/wiring that can be similarly hidden, revealing still more deep structure. this is not just speculation. I have seen this process in the evolution of my own Forth-based language, Abundance. SCIDs will also have another influence on language design. Right now we are stuck in a mindset that a computer language is a linear stream of vanilla 7-bit ASCII characters. SCIDs will loosen that up. We are already seeing that with tools like the Symantec layout editor. A program can be a diagram in 2D. Font style can have semantic meaning. Noam Chomsy might put it this way, programs may have many temporary surface representations of a single deep structure. We will see multiple alias names for variables, multilingual variants of the Strings that can be flipped with the click of a menu item. A SCID could potentially store a lot more information, (not normally visible) than a text file representation would. For example, you could fairly easily automatically record who changed each individual element in each line of code, why and when and as part of which job layer. See dynamic version control for what I mean by job layer. Global renamings would be labelled as such, not as a million separate little transactions. This information could also be used by the boss to track precisely what a telecommuting employee did during the week. You could add all the commentary you wanted without worrying about overwhelming the reader for whom it was irrelevant. The other information you could track at each node is who has access to look at or change that piece of code. For some notes on how a SCID might be implemented so that many users could be updating the same code simultaneously from several globally dispersed sites, again see dynamic version control. If ever Microsoft, (the inventors of the dancing paperclip), gets ahold of the SCID concept I suspect they will totally misunderstand. A SCID will be a 3D simulation of a Disneyland ride where you passively watch transactions being processed by a McDonald's hamburger machine to the endlessly repeating strains of It's A Small Small World. To debug, you watch the individual bits shaped like French fries being cooked, salted then "added", get it? It takes only 10 seconds for the animation to complete the addition of two numbers. Have a look at Visual SlickEdit. It is

7

Limitations of the Unix philosophy and the ultimate solution to parsing https://yinwang0.wordpress.com/2011/04/14/unix/

unix says text streams are the ultimate data format

but parsing is a pain

2

what if we had a standard data format that could communicate some basics - integers, booleans, records

huh sounds kinda like JSON. pretty much has become the de facto serialization format for structured data

also, programs should be encoded as an AST, not as text

https://yinwang0.wordpress.com/2012/01/03/ydiff/ a structured diff, way cool

5

On the Speed of Light, Innovation, and the Future of Parsing http://www.codekana.com/blog/2009/04/02/on-the-speed-of-light-innovation-and-the-future-of-parsing/

I’ve always loved the popular story about how early 20th century physicists thought physics was basically “done”. There were just a couple of minor phenomena lacking an explanation, and it was widely believed that they would soon be fully understood. The whole building of physical law would be finished in a matter of years. These “minor phenomena” were the photoelectric effect and the apparently constant speed of light regardless of the observer, as shown by Michelson and Morley in their famous experiment.

2

want this visualization

properly handling partial invalid syntax while writing an if block or something

36

Tools

5

pigment.io http://pigment.io/ https://github.com/joelburget/pigment/ (joel)

last touched a year ago :(

based on Epigrapm http://en.wikipedia.org/wiki/Epigram_%28programming_language%29

uses dependent types

Tutorial here: 41 pages http://cs.ru.nl/~freek/courses/tt-2010/tvftl/epigram-notes.pdf

19

Less interesting

2

LOP

Language Oriented Programming: The Next Programming Paradigm http://www.onboard.jetbrains.com/is1/articles/04/10/lop/

10

For DSLs

Lanugage Workbenches http://martinfowler.com/articles/languageWorkbench.html

PWCT https://www.youtube.com/watch?v=932OgTYhjJU

2

Skribler http://skribler.sourceforge.net/

graphiql - graphql's structured editor

3

citrus + barista https://github.com/andyjko/citrus-barista

https://www.youtube.com/watch?v=gAxjUh9d2YI

http://www.cs.cmu.edu/~NatProg/barista.html

Alice http://www.alice.org/index.php

LAVA http://lavape.sourceforge.net/ 2013

5

Deoku http://javaeditor.org/doku.php

deubgging, structure lighlighting, and UML diagramming

2
structograms

structograms

this is wild

org-mode (I should look into this more)

2

61 linkes :D https://del.icio.us/KirillOsenkov/StructuredEditors

went through it

http://web.archive.org/web/20150811064219/http://symbolflux.com/projects/tiledtext

Also the witheve.com and lighttable blog posts

4

Subtext http://www.subtext-lang.org/

subtext stuff http://alarmingdevelopment.org/?p=680

feels suuuper similar to `witheve`, simliar goals? but with a GUI builder

I wouldn't call it a structured editor

On the subject of using nameless hashes in software development, to "solve" the naming problem, I wrote this article a while ago: http://thinkinghard.com/blog/DisorganizedIncrementalSoftwareDevelopment.html

https://en.wikipedia.org/wiki/Folding_editor#Editors_with_folding_capability

16

Not an SE

https://twitter.com/KentBeck/status/311983951218630656?lang=en

http://conal.net/papers/Eros/

http://explainshell.com/

2

http://www.rebelscience.org/Cosas/COSA.htm

umm looks like an FRP kind of thing?

2

https://github.com/gocircuit/escher

2 years old

2

http://inform7.com/

Inform is a design system for interactive fiction based on natural language. It is a radical reinvention of the way interactive fiction is designed, guided by contemporary work in semantics and by the practical experience of some of the world's best-known writers of IF.

2

https://github.com/zwegner/mutagen

Inform is a design system for interactive fiction based on natural language. It is a radical reinvention of the way interactive fiction is designed, guided by contemporary work in semantics and by the practical experience of some of the world's best-known writers of IF.

2

https://speakerdeck.com/mtrimpe/graphel-the-meaning-of-an-immutable-world

ummm thinking about state machines, immutabiliyt

Alive https://comealive.io/

http://sclang.sourceforge.net/index.php?p=Media

http://gtoolkit.org/

2

other stuff

apparatus https://groups.google.com/forum/#!forum/aprtus

3

other cool things (visual coding, flow-based)

http://research.microsoft.com/en-us/people/smcdirm/liveprogramming.aspx

noflo - seems dead

12

not code, but text editor

https://prosemirror.net/

2

http://www.memobuild.com/

https://news.ycombinator.com/item?id=1671861

https://ulyssesapp.com/

https://github.com/andreypopp/markstruct

https://github.com/oltodo/hodorjs

https://github.com/patternseek/pnsk-structured-editor

https://prismic.io/blog/structured-text-a-cleaner-way-to-deal-with-rich-text

https://clearly.pl/tutorial/

https://gingkoapp.com

12

Other stuff

5

Purebuilder http://translate.google.com/translate?sl=ru&tl=en&u=http%3A%2F%2Fsites.google.com%2Fsite%2Fpurebuilder%2F

this is lots of russian

referenced post: Why do we write and store the code in a text file?

https://translate.googleusercontent.com/translate_c?depth=1&rurl=translate.google.com&sl=ru&tl=en&u=https://habrahabr.ru/company/infopulse/blog/302146/&usg=ALkJrhidl94j7ODGTUkW3xGkvdJk7NtL0Q

2

Program tree editor http://web.archive.org/web/20160309080807/http://programtree.com/

4

http://web.archive.org/web/20130901162054/http://osteele.com/posts/2004/11/ides

So this is claiming that language features and tooling are at odds

what of lamdu?

what of shem/golem?

6

Talk abt TN welfare

the stake president overrides local leaders, saying "doesn't matter, just write them a check"

lot sof people getting baptized just to work the system, they don't go

everything is under the table

don't want a bank because they're working under the table

"we haven't had true free markets, maybe ever" :t: you say that as if it's desirable